. I bet we could
get some real money together to pay more developers. Also maybe you
could reach out to Mr. Bartels from Kopano, because it should be in
their interest as well to have a wider userbase, shouldn't it?
Best regards
Martin Wolf
Package: kopano-server
Version: 8.7.0-3
|Severity: important|
The Kopano server is built without KCOIDC support, thuswhen enabling e.g.
kcoidc_issuer_identifier = https://meet.example.net
in /etc/kopano/server.cfg, this leads to the followingerrors in the
/var/log/kopano/server.log file:
I forgot to mention, that this incompatibility renders the entire
active-sync part unusable, because the mobile clients can't send or
receive emails and also delays e.g. outlook and thunderbird because of
the high server load.
Package: kopano-server
Version: 8.7.0-3
severity: grave
After I completed my migration of my mails and the attachments to my Debian 10
system with Kopano 8.7.0-3 my last step was
to get z-push working.
After a few hours kopano-server produced 1.xx load and filled my z-push
errorlog faster
Package: kopano-gateway
Version: 8.7.0-3
While running Kopano I encountered a crash of kopano-gateway on my
server with this log output:
Wed Aug 21 09:02:01 2019: [NotifyThread|T11069] [crit ]
--
Wed Aug 21 09:02:01 2019:
In my LDAP based (SambaAD) setup, the standard admin.cfg configuration
you mentioned is NOT working at all.
I fetched the file from kopano sources.
If I create a new user within SambaAD NO store is being created.
Therefore I switched back to my hardcoded locales for now.
I will elaborate this
Based on the fact that /etc/kopano/searchscripts/attachments_parser.db
can contain arbitrary tools that need to be allowed via AppArmor (in
order to make kopano-search doing its job and indexing attachments), it
likely makes sense to allow arbitrary scripts/executables for
kopano-search in
I was thinking about
"/usr/bin/pdftotext ix,"
maybe we need "ux" instead? because the location of the attachments is
not in the apparmor profile.
Also there is another programm who needs to be executed from kopano-search:
"/usr/bin/iconv ux,"
Aug 11 12:23:27 kernel: [26100.280300] audit:
Package: kopano-search
Version: 8.7.0-3
The default AppArmor configuration file
/etc/apparmor.d/usr.sbin.kopano-search doesn't cover /etc/mime.types,
which is needed to do a proper search index.
When that file is allowed in apparmor two more errors pop up.
1. when kopano-search seams to find a
Package: kopano-dagent
Version: 8.7.0-3
The default AppArmor configuration file
/etc/apparmor.d/usr.sbin.kopano-dagent doesn't cover /etc/ssl/openssl.cnf
Adding "/etc/ssl/openssl.cnf r," to
/etc/apparmor.d/usr.sbin.kopano-dagent seems to help.
Error without the modified AppArmor policy:
Aug
Hello Carsten,
ty, I am glad I can help a little ...
Kopano must have changed the directories in Summer last year. I ran into
it, when I updated my productive system (that will get replaced with
Debian 10 + 8.7.0) to a nightly of 8.6.81.xxx end of August 2018.
Regards
Martin
pEpkey.asc
Package: kopano-server
Version: 8.7.0-3
It seems like $KOPANO_USERSCRIPT_LOCALE doesn't have any impact on the
store language anymore: Setting
> KOPANO_USERSCRIPT_LOCALE="de_DE.UTF-8"
in /etc/default/kopano should lead to German folder names in newly
created users (with fresh stores). However
Package: kopano-server
Version: 8.7.0-3
The default userscript for adding new users in
/usr/lib/kopano/userscripts/createuser tries to execute kscriptrun, but
fails, because it has been relocated (moved).
As of writing, the /usr/lib/kopano/userscripts/createuser contains as
last line:
> exec
Package: kopano-server
Version: 8.7.0-3
The default AppArmor configuration file
/etc/apparmor.d/usr.sbin.kopano-server doesn't cover the default
userscripts in /usr/lib/kopano/userscripts/*, which are required to e.g.
create or delete a new user (or a company/tenancy), thus basically
everything.
Hello Christian,
I am glad I was able to help here. What is the "basic ldap data" you are
looking for?
An (my) example configuration, or do you need something scripted?
Regards
Martin Wolf
On Sat, 3 Aug 2019 11:32:43 +0200 Carsten Schoenert
wrote:
> Control: forcemerge -1 933
Package: kopano-server
Version: 8.7.0-3
/etc/init.d/kopano-server uses /var/run/$NAME.pid for $PIDFILE, evaluating to
/var/run/kopano-server.pid, which is wrong:
1. /var/run is a symlink to /run, which however is root:root with 755, but a
properly configured kopano-server process runs
Package: kopano-server
Version: 8.7.0-3
The default AppArmor configuration file /etc/apparmor.d/usr.sbin.kopano-server
doesn't cover the default LDAP configuration files, which are left by default
in /usr/share/kopano/ldap.*.cfg and just included from /etc/kopano/ldap.cfg
(which is the Kopano
Package: kopano-server
Version: 8.7.0-3
After a fresh installation of kopano-server, the default configuration file
/etc/kopano/ldap.cfg is missing and there is also no example configuration in
/usr/share/doc/kopano-server/example-config/
Package: kopano-server
Version: 8.7.0-3
After a fresh installation of kopano-server, the default configuration file
/etc/kopano/ldap.cfg is missing and there is also no example configuration in
/usr/share/doc/kopano-server/example-config/
Hello Christian,
ty for the link to the fix. I applied it myself so I don't have to wait
for a new release.
to get rid of the error message and make apparmor work proberly, is an
"apt install kopano-search --reinstall" sufficient?
Regards
Martin Wolf
Package: kopano-search
Version: 8.7.0-3
I installed kopano along with other packages like kopano-search on a
fresh Debian 10 Buster.
In the "setting-up" phase I encountered an AppArmor error in package
kopano-search:
Setting up kopano-search (8.7.0-3) ...
AppArmor parser error for
21 matches
Mail list logo
