@longsleep Thank you so much for this detailed explanation! Once I have my setup running I’ll definitely return to the PIE problem and apply all the knowledge you have shared here. :) @fbartels You are right, I could have used the relevant tar files on the community server as well. That was probably my brain demanding a nap. Thanks for pointing it out! I have hit another road block by now that might have to do with kweb, so I am shamelessly plugging it in this thread. Issue: https://FQDN/api/gc returns 404 not found even though kapid and grapi are running. Steps taken: Follow the KC Admin Manual all the way to page 28 SSL certificate for the server [works] Configure and start kopano-server, including SSL, OID settings etc [works] configure and start kweb, including ACME [works] configure and test konnect [works] setup and start grapi [works] setup and start kapi [works] access /api/gc [fails] When kapid is started, the journal is populated like this: [root@testbench kapi-kvs]# systemctl status kopano-kapid ● kopano-kapid.service - Kopano API Daemon Loaded: loaded (/usr/lib/systemd/system/kopano-kapid.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2019-03-20 01:47:20 CET; 46min ago Process: 2051 ExecStartPre=/usr/sbin/kopano-kapid setup (code=exited, status=0/SUCCESS) Main PID: 2053 (kapid) Tasks: 10 (limit: 2371) Memory: 80.0M CGroup: /system.slice/kopano-kapid.service └─2053 /usr/lib/kopano/kapid serve --log-timestamp=false --listen=127.0.0.1:8039 --log-level=info --plugins-path=/usr/lib/kopano/kapi-plugins --iss=https://hostname.domain.de Mär 20 02:32:11 testbench kopano-kapid[2053]: level=error msg="kvs: store initialize failed: failed to open database migration driver: attempt to write a readonly database" Mär 20 02:32:21 testbench kopano-kapid[2053]: level=error msg="kvs: store initialize failed: failed to open database migration driver: attempt to write a readonly database" Mär 20 02:32:31 testbench kopano-kapid[2053]: level=error msg="kvs: store initialize failed: failed to open database migration driver: attempt to write a readonly database" Mär 20 02:32:41 testbench kopano-kapid[2053]: level=error msg="kvs: store initialize failed: failed to open database migration driver: attempt to write a readonly database" All paths mentioned in the journal exist and are owned by kapi:kopano. At first start the error read something along the lines of “cannot open database kvs.db - file does not exist” so I have created an empty .db with sqlite kvn.db - but something seems to still be broken. The logs and journal however don’t provide any useful info to track the issue down. For reference, below is my current kapid.cfg. All folders mentioned here exist and are owned by kapi:kopano. The DB migration scripts also reside where they need to. ############################################################## # Kopano API SETTINGS # OpenID Connect Issuer Identifier. oidc_issuer_identifier= https://hostname.domain.de # Address:port specifier for where kapid should listen for # incoming connections. listen = 127.0.0.1:8039 # Disable TLS validation for all client request. # When set to yes, TLS certificate validation is turned off. This is insecure # and should not be used in production setups. #insecure = no # Comman separated list of plugin names which should be loaded. # If this is not set or the value is empty, kapid scans the plugins_path # on startup and loads all plugins found. #plugins = # Path to the location of kapi plugins. plugins_path = /usr/lib/kopano/kapi-plugins ############################################################### # Log settings # Log level controls the verbosity of the output log. It can be one of # `panic`, `fatal`, `error`, `warn`, `info` or `debug`. Defaults to `info`. log_level = info ############################################################### # Groupware REST API (grapi) Plugin settings # Path where to find Kopano Groupware REST (grapi) sockets. plugin_grapi_socket_path = /var/run/kopano-grapi ############################################################### # Pubs API (pubs) Plugin settings # Path to a key file to be used as secret for Pubs HMAC tokens. # If no secret_key file is set, a random value will be generated on # startup (not suitable for production use, since it changes on # restart). A suitable key file can be generated with # `openssl rand -out /etc/kopano/kapid-pubs-secret.key -hex 64`. #plugin_pubs_secret_key = /etc/kopano/kapid-pubs-secret.key ############################################################### # Key value store API (kvs) Plugin settings # Database backend to use for persistent storage of kvs data. A supported # backend must be set (sqlite3, mysql). Defaults to `sqlite3` if not set. plugin_kvs_db_drivername = sqlite3 # Database backend data source name. This setting depends on the storage # backend (plugin_kvs_db_drivername). A DNS is required to use the kvs plugin. # - For `sqlite3` the value should be the full path to the database file. # - For `mysql`, us a MySQL DSN in the following format: # [username[:password]@][protocol[(address)]]/dbname[?param1=value1&...&paramN=valueN] # See https://github.com/go-sql-driver/mysql#dsn-data-source-name for a # full list of supported MySQL DSN params with examples. # If not set and plugin_kvs_db_drivername is also not set a default value will # be used which uses SQLite3. plugin_kvs_db_datasource = /var/lib/kopano/kapi-kvs/kvs.db # Path where to find the database migration scripts. plugin_kvs_db_migrations = /usr/lib/kopano/kapi-kvs/db/migrations Second issue: My distro does not store webapp files directly under /usr/share but in /usr/share/webapps instead. konnect works, so generally should not be a problem. What I can not figure out is how I can point kweb to the actual kopano webapp. Any hints, please? The following paths when appended to https://FQDN/ return 404 not found /webapp/ /kopano-webapp/ /usr/share/webapps contains this: [root@testbench kapi-kvs]# ls -alh /usr/share/webapps/ insgesamt 40K drwxr-xr-x 7 http http 4,0K 20. Mär 00:22 . drwxr-xr-x 81 root root 4,0K 20. Mär 00:22 .. -rw-r--r-- 1 http http 1,2K 19. Mär 02:42 favicon.ico -rw-r--r-- 1 http http 138 19. Mär 01:37 index.html drwxr-xr-x 6 http http 4,0K 20. Mär 00:22 kopano-kdav drwxr-xr-x 3 konnect kopano 4,0K 20. Mär 00:22 kopano-konnect drwxr-xr-x 3 http http 4,0K 20. Mär 00:22 kopano-meet drwxr-xr-x 5 http http 4,0K 20. Mär 00:22 kopano-webapp -rw-r--r-- 1 http http 26 19. Mär 02:42 robots.txt drwxr-xr-x 8 http http 4,0K 20. Mär 00:22 z-push https://FQDN/ loads index.html which simply contains Hello World!.

Finally it seems that unhooking and hooking the store of the user again solved these kind of error - crossing fingers…

actual neither the tiny nor the minimal editor can handle copied tables. great, so we’ll wait for new editors. sure, we can do this! thanks.

@marty said in Counter on the Mail folders: you execute this in your browsers console to check the polling interval? in the browser the result was: 30 how could i do this in the DeskApp?!?

Hi @irrlicht, I updated my mobile to Android 9 recently and testing afterwards the popup didn’t show up. Manfred

@jasgggit if you use https://you.host-.name/ as Zimbra upstream server in Z-Push it will access zimbra’s public facing ip address (i.e. eth0 address). This means you must whitelist the device IP in DoSFilter. Check here.

Addendum: cd /etc/php/7.3/cli/conf.d ln -s /etc/php/7.3/mods-available/mapi.ini

Oops! Thanks!

Well, figured it out myself, here’s how to solve it, if someone rans into it, too: First, check the https-feature of apt with debug: option: > apt-get update -o Debug::Acquire::https=1 In my case, there have been errors, like “no access to ca_certificates.crt” and so on. The read/write-permissions of /etc/ssl/certs/ were set propperly, so i did reinstall the certificate_ca and apt-transport-https: > apt install ca-certificates apt-transport-https Verifying, with the debug outpout again to see if it got fixed: > apt-get update -o Debug::Acquire::https=1 The errors are gone, doing an apt-get update > apt-get update [...] OK:7 http://ftp.de.debian.org/debian stretch Release Ign:8 https://download.kopano.io/supported/core:/final/Debian_9.0 InRelease Ign:2 https://attic.owncloud.com/org/download/repositories/production/Debian_9.0 InRelease OK:9 http://download.owncloud.org/download/repositories/production/Debian_9.0 Release Ign:10 https://download.kopano.io/supported/webapp:/final/Debian_9.0 InRelease OK:11 https://download.kopano.io/supported/core:/final/Debian_9.0 Release OK:12 https://download.kopano.io/supported/webapp:/final/Debian_9.0 Release Paketlisten werden gelesen... Fertig

I stumbled upon the answer: “The unique user attribute is the mapping between a mailbox in the database and the actual user in LDAP. Make sure this field is never changed as Kopano will perceive that as a user being deleted (and created), and will therefore orphan the user’s store.” R.

apologies, I thought you were referring only to the display. For the memory used, the easiest is perhaps to launch it on a machine and see how much memory it actually uses and then work out the specifications of the hardware you need.

Hi @WalterHof Maybe this is something Univention related? We see the error only on UCS Server. Customers with a debian installation doesn’t report this problem, yet. Kind regards Basti

Hi @scaarup, I am using this kind of configuration on my own system, therefore it should work. I am using it with lmtp transport, though (which should in any case be preferred). Your log line suggests you are delivering via a pipe. What is logged at the dagent at time of delivery?

@fbartels Anyone having the same issues? Still can not update kopano to latest version on centos 7.

Hi @Manfred, I did not contact support yet. Too many possibilities I wanted to rule out. What I have done - just to keep you informed: Complete reinstall of Ubuntu 18.04.2 on a test system with reinstall of Kopano 8.6.9 as well as 8.7.0 with Z-Push 2.4.5 Tested with PHP 7.3 - this included compiling and installing the latest Kopano community version in order to get mapi.so running It is hard to believe that I am the only one with this problem since I built up the system from scratch ending with the same segmentation faults again. Is still no one here experiencing the same problems? Nobody using Ubuntu 18.04.2 as base for a Kopano system? Or the other way round: Anybody using Ubuntu 18.04.2 but not experiencing this issue?

Hi @joja , you are indeed not able to open the inbox of an inactive user via imap. You should could use the new rest api (available from 8.7.0 onwards) for this. We have an internal poc for a mail client based on this, so it should generally work, but might be missing features. Another possibility is to use python-kopano to script this directly, but you won’t be able to do this from windows as python-kopano depends on a few other kopano components. it does not need to run on the same system as your actual kopano installation, any linux system should do (wsl on windows is probably fine as well).

Hi, If someone need’s that info too Its resolved by following this instruction: https://help.univention.com/t/additional-ucs-server-does-not-get-kopano-integration-packages/11477/5?u=externa1 rg Christian