I’m sorry, you lost your bet ;-) - /etc/postfix/aliases actually is an empty file (that I postmapped, of course)

But thanks for clearing up the different formats and the suggestion to rename /etc/postfix/aliases to a kopano-related name.

I use fail2ban with ufw for it on my Debian server

Here you go, what i use.

# /etc/fail2ban/filter.d/kopano-gateway.conf # # Fail2Ban configuration file # Kopano Gateway : /var/log/kopano/gateway.log # [INCLUDES] before = common.conf [Definition] # Option: failregex # Notes.: regex to match the password failures messages in the logfile. The # host must be matched by a group named "host". The tag "<HOST>" can # be used for standard IP/hostname matching and is only an alias for # (?:::f{4,6}:)?(?P<host>[\w\-.^_]+) # Values: TEXT # failregex = Failed to login from <HOST> with invalid username Failed to login from <HOST>:[0-9]{2,5} with invalid username ignoreregex = [Init] journalmatch = _SYSTEMD_UNIT=fail2ban.service

and

# /etc/fail2ban/jail.d/local-jail.conf [kopano-gateway] enabled = false port = smtp,ssmtp,submission,imap2,imap3,imaps,pop3,pop3s filter = kopano-gateway banaction = ufw

Thank you.

@afischer said in Kopano 8.7.9 on CentOS 7.7: movetopublicfolder.py error No module named 'ConfigParser':

Is there any actual documentation about “preferred” dependencies or discontinued support of packages?

the quoted sentence was in relation to the nightly packages and not the supported release packages. The “Edition 8.3.0 - Kopano Team” in https://documentation.kopano.io/kopanocore_administrator_manual/ is just a number set in the sources of the documentation, it does not reflect the version of Kopano it refers to.

Officially supported distributions are stated in the manual. But my personal recommendation would be to go for a Debian based system as it has the largest user base among Kopano users and therefore receives the most testing.

Is there a way to check in the z-push log whether a user has deleted a folder? How would this be logged in z-push?

8.7.8 spec:

%package dagent Summary: E-Mail Delivery Agent for the Kopano platform Group: Productivity/Networking/Email/Servers Requires(pre): kopano-common = %version Requires: kopano-dagent-pytils >= 8.7.6.7 Requires: kopano-lang = %version %if 0%{?suse_version} || 0%{?fedora_version} # kcpyplug is dlopened / RedHat7 has no Recommends Recommends: libkcpyplug0 = %version %endif

Thank you, I’ll try

@jengelh said in Kopano-Gateway crashes (SIGABRT):

Fixed in kopanocore-8.7.7-24-g86547b380 / kopanocore-8.7.85-63-g151d70c22

Fix was included in kopanocore-8.7.84-140-g5f74297a5 .

There is a better error message since 8.7.7 for the config file open error.

Are there any updates for a Fix of the Plugin?

Markus

I managed to fix it by myself.

Just did a
item.create_prop(0x81b60040, value=item.start)
item.create_prop(0x81b70040, value=item.end)

over all calendar items. This makes them visible again.
I can post the whole script later, if someone needs it.

you should run this is a tmux or screen session!

#!/usr/bin/python3 # This script sets all the special start and stop kopano properties for all calendar entries # To fix the following problem: # User PST files are imported in Kopano, but calendar items doesn't appear in calendar view # (only in list view) # If an entry in list view is clicked and saved, it becomes visible in calendar view as well # To make them all visible at once for all users run this script import kopano calendar_name = 'Kalender' server = kopano.Server() for user in server.users(): print('-------------') print(user.name) print('-------------') cal = None for folder in user.store.folders(): if folder.name == calendar_name: cal = folder print('Kalender gefunden') if not cal: print('kein Kalender da?') continue for item in cal.items(): print(item.subject) item.create_prop(0x81b60040, value=item.start) item.create_prop(0x81b70040, value=item.end) print(' ') print(' ')

Anything that does not rely on fetching mails after delivery, but instead hooks into your mailflow directly should be good.

Hi @cr4pzje,

I would recommend to use Debian/Ubuntu as a base instead. Only a fraction of our customers is using CentOS, which means that (especially for the nightly downloads) it does not get our full attention. You have much more success with a deb based system.

Looks like schema 63 (the cutoff point) was already present in 7.1 (not just 7.2), so KC 8.7 is still able to upgrade from that.

“host” is a bit misleading.
First, you do need two instances of kopano-server. Although these can be placed in one namespace, the extra work to get there is usually not worth the trouble, so two namespaces is the recommended separation. Whether the namespaces are on the same host — in any imaginable interpretion of “host” — or on different ones is up to the administrator.

but thats the strang thing, all work, execpt search.
i normaly see things like :

2019-12-03T10:24:56.045667: [=======] Starting kopano-spooler version 9.0.1 (pid 26552 uid 0) 2019-12-03T10:24:56.069025: [=======] Starting kopano-spooler version 9.0.1 (pid 26552 uid 999)

i just increase the log level to 6 for search,… still 0kb …

i saw these in syslog

Dec 3 14:02:07 mail1 kopano-search[27567]: Terminating on signal 15 Dec 3 14:02:07 mail1 systemd[1]: kopano-search.service: Main process exited, code=exited, status=1/FAILURE Dec 3 14:02:07 mail1 systemd[1]: kopano-search.service: Failed with result 'exit-code'. Dec 3 14:02:07 mail1 systemd[1]: Stopped Kopano Groupware Core Search Daemon. Dec 3 14:02:11 mail1 systemd[1]: Started Kopano Groupware Core Search Daemon.

search works fine as far i can tell.

exact version is : 9.0.1.4.389db7f95-0+197.1 amd64

Hi @thctlo

I’m sorry I was moving into a new place and a lot of stuff to do. Now I’m back but no luck and it looks like nothing has changed.

I have a test enviroment so easy if it’s not working. Can you take again a look into this?

Holen:9 file:/home/kopano/apt amd64/ Packages Fehl:9 file:/home/kopano/apt amd64/ Packages Datei nicht gefunden - /home/kopano/apt/amd64/Packages (2: No such file or directory) Holen:10 file:/home/kopano/apt amd64/ Translation-de_DE Ign:10 file:/home/kopano/apt amd64/ Translation-de_DE OK:13 http://archive.ubuntu.com/ubuntu bionic InRelease OK:14 http://archive.ubuntu.com/ubuntu bionic-updates InRelease OK:15 http://archive.ubuntu.com/ubuntu bionic-backports InRelease OK:16 http://security.ubuntu.com/ubuntu bionic-security InRelease Paketlisten werden gelesen... E: Fehlschlag beim Holen von file:/home/kopano/apt/amd64/Packages Datei nicht gefunden - /home/kopano/apt/amd64/Packages (2: No such file or directory) E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.

It seems that I only get the issue when I´ve set
enable_enhanced_ics = no in server.cfg

We received a similiar message and did some research before allerting anyone.
Our security systems cleared the Sender, Domain and involved Servers so we got in contact with kopano and got these, quite old, serials removed.
No need to trouble anyone. Took us about 10 minutes to verify all.