@jengelh said in Debian Stretch: kopano-monitor not starting, "unable to initialize locale":

error message was “unable to initialize locale”. this happend on a system with non en_US locale.

You should make sure the locale is actually installed before trying to make use of it.

Good point @jengelh , on Debian this is normaly already installed, then its only enabling it.
run : dpkg-reconfigure -plow locales select the needed locales and restart the kopano service.

that was fixed on Oct 24.

» tar -tf core-8.7.80.12_0+11-Debian_9.0-amd64.tar.gz | grep pypl core-8.7.80.12_0+11-Debian_9.0-amd64/./libkcpyplug0-dbgsym_8.7.80.12-0+11.1_amd64.deb core-8.7.80.12_0+11-Debian_9.0-amd64/./libkcpyplug0_8.7.80.12-0+11.1_amd64.deb

@fbartels
Thanks for the information.

https://documentation.kopano.io/kopanocore_administrator_manual/upgrading.html#migrating-database-attachments-to-files

What i did in the end is just look harder to find that version 7.2.3… (Couldn’t find it at first.) and decided to update my current version to 7.2.4. (After making a good backup of course :-)

Using the following commands:
###Download stuff
wget http://archives.z-hub.io/7.2/zcp-7.2.4.29-ubuntu-14.04-x86_64-opensource.tar.gz
tar -zxcf zcp-7.2.4.29-ubuntu-14.04-x86_64-opensource.tar.gz
cd zcp-7.2.4.29-ubuntu-14.04-x86_64-opensource/
###Create apt package.list
sudo su
apt-ftparchive packages . | gzip -9c > Packages.gz && echo “deb file:$(pwd) ./” > /etc/apt/sources.list.d/zarafa.list
###Install updates
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

After this i went from ZCP 7.1.14-51822 to ZCP 7.2.4-29. The migration task is now much easier.

Thanks for your reply. You made my day. :-)

Thanks for the report. This has been edited and the next upload (occurs around 01:50 local timezone each day, it seems) should have it fixed.

@fbartels

No problem thank you for your work and effort👍👍👍

let’s first check if everything is better now. the patches have been merged to our 8.7 branch. I will let you know once they hit master.

@jmx it sounds strange that recreating the index always only fills the index to the date that the index has been recreated. I would recommend to get in contact with our support to have a deeper look on the system.

It may be an idea to update to the latest dot release first. https://wiki.z-hub.io/display/K4U/Updating+Kopano+packages+directly+from+the+Kopano+download+server has instrictions on how to do that with Univention.

Alredeay find the problem. For anyone ho has the same as me. stop kopano-search and then start the import. then i find all is ok to import and the server does not crash.

please see the other post for updates.

i will create a new topic for this problem

That explains my issues. Thx. I’ve resolved this with a cronjob. I would prefer not having to copy and chown ssl certs “all over the place” though. But at least it’s working fine now.

@tph2018 said in kopano-core nightly builds Fedora broken:

core-8.6.82.0_0+105-Fedora_28-x86_64.tar.gz
However, what is inside the tarball is from version 8.6.81.249-40.1

this is a side effect of how we create the download archives. If one of our focus distributions fails to compile (so one of the distributions where there is official support for Kopano customers for) then this blocks the nightly release process. Fedora is not one of these distributions and they were already failing for a while. This results in a download archive being created during the nightly release with the “about to be released” version in the filename, but with the last successful built inside of the archive.

For webapp there seems to be a problem with the internal repo as well.

anyhow. …

I know that I had a similar issue with kopano core a few months ago and I had to merge

cat cert.pem privkey.pem >> kopano.pem

should be at least.

cat privkey.pem cert.pem >> kopano.pem

Always first key then cert in combined certificate.

ssl_private_key_file = /etc/letsencrypt/live/domain.xx/privkey.pem #ssl_private_key_file = /etc/kopano/gateway/privkey.pem #File with certificate for SSL ssl_certificate_file = /etc/letsencrypt/live/domain.xx/cert.pem

The CA is already integrated in /etc/ssl/cert/ca-certificates.

Just point the CA to that file or point to one in letsencrypt.

Hai, try the following.

apt-cache policy kopano-server kopano-search

And post the outpot.

if you use a local repo ( file repo ) ,
try this :

deb [trusted=yes] …

but lets start with the policy info.

https://packages.ubuntu.com/search?keywords=xapian-tools
Ok, i can explain the problem here is.

The Ubuntu packages (same for the Debian packages) have some other packages then the kopona repo ( and community packages ).
Due to the differences here you have this.

You might need to set a preferences file also for the kopano packages and give the version you preffered a higher pinning.

read : https://www.howtoforge.com/a-short-introduction-to-apt-pinning
That is a good example.

Hi,

admin manual: https://documentation.kopano.io/kopanocore_administrator_manual/configure_kc_components.html#configure-language-for-store-creation
states: “for example nl_NL.UTF-8 or fr_FR.UTF-8.”
I use this line: "default_store_locale = de_DE.UTF-8 "and it works.

Thanks for the advice. I will be sure to check the IDs and performance before migrating fully.

A note in case anybody’s considering the same, the plan is to set up the Kopano server as a RODC (read only domain controller). In my testing so far I’ve found that it’s necessary to add Kopano users to the “Allowed RODC Password Replication Group” and also to run “samba-tool rodc preload username” for each user. I have a script which automates that step, only preloading user objects that have been modified since the last time it was run (preloading is very slow). The preload step appears to be necessary both for LDAP binds to work and for the Kopano attributes to be synchronized.