The kopano installation does not pull in any of the spell checker libraries. It will require a bit of rework because of the app-kopano-basic-extras package which just lists all the rest of the packages available but not installed by default. This is really just to make the repos make the packages available to paid users. This should be minor.

With the update of Webapp 4.0, the spellchecker functionality within webapp will be depreciated.

Please note: IE11 support will be dropped with WebApp 4.0 final and spellchecker packages will no longer be shipped. We recommend using the browsers build in spellchecker.

https://forum.kopano.io/topic/3053/webapp-4-0-beta-1-available

Not sure this will give an depency issue with the packages. I did not notice this when I did a test using the Kopano repos to update

Nick Howitt wrote:

Neither of my systems had kopano-webapp-plugin-delayeddelivery installed - perhaps because kopano-webapp obsoleted the requirement in app-copano-core. Anyway, once the mirrors sync, you should be able to do:

yum update app-kopano --enablerepo=clearos-paid-testing

This should just remove the dependency. It may be a little OTT as I've also made it obsolete kopano-webapp-plugin-delayeddelivery, but I think kopano-webapp does that as well.

Looks like it is working

I've tested it with Kopano-Core 8.7.5 and 8.7.9, both updated Webapp 3.5.12.2482 to 4.0.2652 (latest community release from Kopano)

Nick Howitt wrote:

It looks like you are right. There are a number of plugins installed by app-kopano-core and I don't know the history of them. Because of the repo set up, removing the dependency is not quite so straightforward, but it shouldn't be too hard. I'll put it on my list.

[edit]
Do you know anything about the following plugins:

kopano-webapp-plugin-contactfax

kopano-webapp-plugin-filepreviewer

kopano-webapp-plugin-folderwidgets

kopano-webapp-plugin-gmaps

kopano-webapp-plugin-pimfolder

kopano-webapp-plugin-quickitems

kopano-webapp-plugin-titlecounter

kopano-webapp-plugin-webappmanual

[/edit]

I'm not sure which plugins are mandatory, but these plugins are part of the package from Kopano

kopano-webapp-plugin-contactfax

kopano-webapp-plugin-desktopnotifications

kopano-webapp-plugin-filepreviewer

kopano-webapp-plugin-folderwidgets

kopano-webapp-plugin-gmaps

kopano-webapp-plugin-htmleditor-minimal-tinymce

kopano-webapp-plugin-htmleditor-quill

kopano-webapp-plugin-intranet

kopano-webapp-plugin-mattermost

kopano-webapp-plugin-pimfolder

kopano-webapp-plugin-quickitems

kopano-webapp-plugin-spell

kopano-webapp-plugin-spell-de-at

kopano-webapp-plugin-spell-de-ch

kopano-webapp-plugin-spell-de-de

kopano-webapp-plugin-spell-en-gb

kopano-webapp-plugin-spell-en-us

kopano-webapp-plugin-spell-es-es

kopano-webapp-plugin-spell-fr-fr

kopano-webapp-plugin-spell-it

kopano-webapp-plugin-spell-nl

kopano-webapp-plugin-spell-pl-pl

kopano-webapp-plugin-titlecounter

kopano-webapp-plugin-webappmanual

threema4deskapp

kopano-webapp-plugin-zdeveloper

whatsapp4deskapp

To my opinion no all plugins are mandatory in the dependencies to use Webapp, but maybe only these

kopano-webapp-plugin-spell

kopano-webapp-plugin-spell-de-at

kopano-webapp-plugin-spell-de-ch

kopano-webapp-plugin-spell-de-de

kopano-webapp-plugin-spell-en-gb

kopano-webapp-plugin-spell-en-us

kopano-webapp-plugin-spell-es-es

kopano-webapp-plugin-spell-fr-fr

kopano-webapp-plugin-spell-it

kopano-webapp-plugin-spell-nl

kopano-webapp-plugin-spell-pl-pl

kopano-webapp-plugin-titlecounter

kopano-webapp-plugin-webappmanual

The other are nice to have and can be added if needed.
These plugin are loose .rpm files in the repositories

Neither of my systems had kopano-webapp-plugin-delayeddelivery installed - perhaps because kopano-webapp obsoleted the requirement in app-copano-core. Anyway, once the mirrors sync, you should be able to do:

yum update app-kopano --enablerepo=clearos-paid-testing

This should just remove the dependency. It may be a little OTT as I've also made it obsolete kopano-webapp-plugin-delayeddelivery, but I think kopano-webapp does that as well.

It looks like you are right. There are a number of plugins installed by app-kopano-core and I don't know the history of them. Because of the repo set up, removing the dependency is not quite so straightforward, but it shouldn't be too hard. I'll put it on my list.

[edit]
Do you know anything about the following plugins:

kopano-webapp-plugin-contactfax

kopano-webapp-plugin-filepreviewer

kopano-webapp-plugin-folderwidgets

kopano-webapp-plugin-gmaps

kopano-webapp-plugin-pimfolder

kopano-webapp-plugin-quickitems

kopano-webapp-plugin-titlecounter

kopano-webapp-plugin-webappmanual

[/edit]

Nick,

It looks like there is still an old dependency in the app-kopano-core to kopano-webapp-plugin-delayeddelivery
kopano-webapp-plugin-delayeddelivery is obsolete since webapp 3.3.0 and part of koapne-core.

https://kopano.com/releases/webapp-3-3-0-beta-1-now-available/

Are you able to remove this dependency, because it it blocking now the webapp 4.x update (i'm testing ......)

Nick Howitt wrote:

Any chance of a further test update:

yum update app-kopano app-kopano-core --enablerepo=clearos-paid-testing

We missed that IMAP and POP are defaulted off in a new installation. I've also moved the certificate initialisation to the install script from the update script.

Both changes should have no effect on an installation made before the update, but for new updates IMAP/POP should now be working (preffed on by "disabled_features =" rather than "#disabled_features = imap pop3" in /etc/kopano/server.cfg which defaulted it to off) or any new installation which installed 8.7.5 directly.

I've made a fresh install with the latest ISO and a install of Kopano with the test-update.
POP3 is working without any problems

Any chance of a further test update:

yum update app-kopano app-kopano-core --enablerepo=clearos-paid-testing

We missed that IMAP and POP are defaulted off in a new installation. I've also moved the certificate initialisation to the install script from the update script.

Both changes should have no effect on an installation made before the update, but for new updates IMAP/POP should now be working (preffed on by "disabled_features =" rather than "#disabled_features = imap pop3" in /etc/kopano/server.cfg which defaulted it to off) or any new installation which installed 8.7.5 directly.

Hmm. Commenting out the mysql_host line is not a good idea (fatal). There is no problem within kopano, but the 4-byte UTF8 upgrade command "kopano-dbadm usmp" fails and wrecks things.

Attached is probably my final upgrade package with the better kopano-condrestart script.

Longer term a release will be needed to try to comment out all parameters set in 8.4.5 and 8.5.8 which are defaulted and commented out in 8.7.5 but this can wait.

The first four lines come from terminating kopano-search and the last from terminating kopano-server. As this is during a restart process the subsequent starts work OK. I am not sure I can do anything about it.

Nick Howitt wrote:

In 8.7.5 you can comment out the mysql_host line as it defaults to empty.

Nick,

In messages.log i see an error, but the kopano-search is running.

Oct 12 16:10:57 pdebrabander kopano-search: Terminating on signal 15

Oct 12 16:10:57 pdebrabander systemd: kopano-search.service: main process exited, code=exited, status=1/FAILURE

Oct 12 16:10:57 pdebrabander systemd: Unit kopano-search.service entered failed state.

Oct 12 16:10:57 pdebrabander systemd: kopano-search.service failed.

Oct 12 16:11:03 pdebrabander kopano-server: Error in my_thread_global_end(): 16 threads didn't exit

In 8.7.5 you can comment out the mysql_host line as it defaults to empty.

Hmm. It works on 8.5.8 but it looks like on 8.7.5 you also have to set mysql_host to localhost (not 127.0.0.1) or leave it empty. I've tested setting it to localhost. I'm pretty sure I forced this to 127.0.0.1 in the update script for some reason but I can reverse that bit.

Nick Howitt wrote:

That's the one. Give it a go, restarting kopano-server. To prove it, I stopped kopano for a few minutes then I started it so the logs would be separate.

i tried it, but still the error during startup:

2019-10-11 20:06:04,115 - search - ERROR - Traceback (most recent call last):

  File "/usr/lib/python2.7/site-packages/kopano/log.py", line 103, in log_exc

    try: yield

  File "/usr/lib/python2.7/site-packages/kopano_search/__init__.py", line 393, in incremental_sync

    new_state = self.server.sync(importer, self.state, log=self.log)

  File "/usr/lib/python2.7/site-packages/kopano/server.py", line 853, in sync

    return _ics.sync(self, self.mapistore, importer, state, max_changes, window=window, begin=begin, end=end, stats=stats)

  File "/usr/lib/python2.7/site-packages/kopano/ics.py", line 253, in sync

    exporter.Config(stream, flags, importer, restriction, None, None, 0)

  File "/usr/lib/python2.7/site-packages/MAPICore.py", line 1346, in Config

    def Config(self, *args): return _MAPICore.IExchangeExportChanges_Config(self, *args)

MAPIErrorNetworkError: MAPI error 80040115 (MAPI_E_NETWORK_ERROR)

That's the one. Give it a go, restarting kopano-server. To prove it, I stopped kopano for a few minutes then I started it so the logs would be separate.

Nick Howitt wrote:

I have a fix for the search error. Kopano is using system-mysql so it does not use the default socket. In server.cfg change:

mysql_socket		=

to:

mysql_socket = /var/lib/system-mysql/mysql.sock

Nick, is this related to this error ?
https://www.clearos.com/clearfoundation/social/community/update-kopano,-webapp-and-z-push#reply-271511

I have a fix for the search error. Kopano is using system-mysql so it does not use the default socket. In server.cfg change:

mysql_socket		=

to:

mysql_socket = /var/lib/system-mysql/mysql.sock

Here is a new set files, mainly with kopano-condrestart doing httpd first and then the kopano services. There are a few other tidy ups.

Note that in the install script httpd is still started after the kopano services and I believe that works fine as it always has so I am a bit perplexed with your issue.

Nick Howitt wrote:

That is frustrating. I've done a number of trial upgrades and I've not seen that. Perhaps httpd needs to restart before kopano-???. I don't really want to restart httpd twice as the restart is slow. There is no such process as kopano-webapp, so perhaps apache should be brought to the beginning of the restarts? When I've upgraded all I've had to do is refresh the webapp page in the browser and it comes up with the new version (requiring a login).

Where were you seeing the message? In your browser?

Maybe because my webapp was not update because i was already on the latest version.

That is frustrating. I've done a number of trial upgrades and I've not seen that. Perhaps httpd needs to restart before kopano-???. I don't really want to restart httpd twice as the restart is slow. There is no such process as kopano-webapp, so perhaps apache should be brought to the beginning of the restarts? When I've upgraded all I've had to do is refresh the webapp page in the browser and it comes up with the new version (requiring a login).

Where were you seeing the message? In your browser?

Nick Howitt wrote:

Hi Patrick, can you please clarify? Are you talking about the upgrade to 8.7.5? If so, the last part of the /usr/clearos/apps/kopano/deploy/upgrade script does a "kopano-condrestart" which restarts apache (httpd). Or are you talking about the manual upgrade from 8.4.5 to 8.5.8? Even then, the last step is to restart the services including httpd. Or are you perhaps using a different version of PHP from the PHP Engines app.

Sure.
I did an upgrade from 8.5.8 to 8.7.5.
After the upgrade I checked the Webapp and this was telling to restart http-server to reload php.ini for mapi (don't know the exact message anymore)

But something like this :

Not Found: PHP mapi extension not found



If you have upgraded Kopano Core, please restart Apache



Kopano WebApp can't start because of incompatible configuration.



Please correct above errors, a good start is by checking your 'php.ini' file.



You can disable this configuration check by editing the file '/usr/share/kopano-webapp/config.php', but this is not recommended.

Hi Patrick, can you please clarify? Are you talking about the upgrade to 8.7.5? If so, the last part of the /usr/clearos/apps/kopano/deploy/upgrade script does a "kopano-condrestart" which restarts apache (httpd). Or are you talking about the manual upgrade from 8.4.5 to 8.5.8? Even then, the last step is to restart the services including httpd. Or are you perhaps using a different version of PHP from the PHP Engines app.

Hi Nick,

I did the upgrade on my production server.
Upgrade went smoothly and the kopano server is running without any (know) issues at this moment.
Emails are coming in.

The only thing to add to the upgrade script is to restart the http server. Webapp is asking for it after the upgrade to reload the php.ini

That, fortunately for me, is not an upgrade issue. That is a separate marketplace issue. Can you try a general "yum update" first?

Nick,

I'm trying to update from 8.4.5, but unfortunately the upgrade is not working
ClearOS release 7.6.0 (Final)

ENABLE_BETA=True yum upgrade "*kopano*" "lib*" "python*"

Loaded plugins: clearcenter-marketplace, fastestmirror

ClearCenter Marketplace: fetching repositories...

ClearCenter Marketplace: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618)

Loading mirror speeds from cached hostfile

 * clearos: mirror2-amsterdam.clearos.com

 * clearos-centos-sclo-rh: download1.clearsdn.com

 * clearos-contribs: mirror2-amsterdam.clearos.com

 * clearos-fast-updates: download1.clearsdn.com

 * clearos-infra: mirror2-amsterdam.clearos.com

No packages marked for update

On an other image it worked.
Upgrade from 8.4.5 -> 8.5.8 -> 8.7.5

Nick Howitt wrote:

Perhaps I should remove presence.cfg as well as it is no longer used.

Yep.

Also Kopano Web meetings is installed standard.
This is an extra paid package with a difference license

Perhaps I should remove presence.cfg as well as it is no longer used.

Those parameters don't exist in the 8.5.8 install. You can check in /usr/share/doc/kopano/example-config.

Anyway I have fixed it and added back in backing up of the configs during the upgrade but I did not bump the version (and don't intend to or I'd have run out of numbers by now!)

Nick Howitt wrote:

Hmm. Was that originally an 8.4.5 installation? If so, I'll have to install one. Those parameters are are missing completely from native 8.5.8 configs.

It was an upgrade from 8.5.8 to 8.7.5
I'll check tonight, but i thought was a originally a 8.5.8 install

Hmm. Was that originally an 8.4.5 installation? If so, I'll have to install one. Those parameters are are missing completely from native 8.5.8 configs.

Nick Howitt wrote:

I think it is all working now for installs and updates.

From the zip file, ..........................

work for the moment.

Hi Nick,

I did a upgrade test from 8.5.8 to 8.7.5 and the upgrade package went smoothly execpt kopano-server did not start.
The following error is shown:

Sep 25 19:14:23 server2.pdebrabander.nl kopano-server[5207]: [crit   ] Config error: Unknown option "server_tcp_enabled" found!

Sep 25 19:14:23 server2.pdebrabander.nl kopano-server[5207]: [crit   ] Config error: Unknown option "server_tcp_port" found!

Sep 25 19:14:23 server2.pdebrabander.nl kopano-server[5207]: [crit   ] Config error: Unknown option "server_ssl_enabled" found!

Sep 25 19:14:23 server2.pdebrabander.nl kopano-server[5207]: [crit   ] Config error: Unknown option "server_ssl_port" found!

Sep 25 19:14:23 server2.pdebrabander.nl kopano-server[5207]: An error occurred: no access (0x8004011c). Please check logfile file:/var/log/kopano/server.log for details.

Sep 25 19:14:23 server2.pdebrabander.nl kopano-server[5207]: [=======] Server shutdown complete.

Sep 25 19:14:23 server2.pdebrabander.nl systemd[1]: kopano-server.service: main process exited, code=exited, status=255/n/a

Sep 25 19:14:23 server2.pdebrabander.nl systemd[1]: Unit kopano-server.service entered failed state.

Sep 25 19:14:23 server2.pdebrabander.nl systemd[1]: kopano-server.service failed.

I have comment them out in server.cfg to start the kopano-server.
This should be added in your update script

The previous packages worked to upgrade 8.5.8 or do a fresh install, but needed reworking to accommodate a direct upgrade from 8.4.5.

Note that if you are using these files to upgrade directly from 8.4.5 following these instructions (amending the yum command to the one in this thread) you will need to start kopano-server, kopano-gateway and kopano-dagent manually at the end of the upgrade process. I will update the upgrade instructions when this package gets released.

New files are attached.

I think it is all working now for installs and updates.

From the zip file, place kopano.repo in /etc/yum.repos.d. Then edit the repo file, replacing "YOURSERIALNUMBER" with your serial number that you should be able to find from your Webconfig.

Place the four rpm's in a folder of your choice then, in ssh, navigate to that folder and run:

yum update app-kopano* kopano-webapp* --enablerepo=Kopano-Core,z-push,Kopano-Webapp --nogpgcheck

In the Webconfig, you can now set a port to **blank** and it will disable the service.

You will find in the webconfig that the "Secure iCal Port" is blank. This is because, although it shows as 8443 with Kopano 8.5.8, it is actually disabled due to another pref and the certificates are not set up to enable it to work. In 8.7.5 upgrade, I have set up the certificates to work but not enabled it as this, in effect, changes a current preference which the user may not want to do. If you want to enable "Secure iCal Port", just set it to 8443 or a port of your choice and it should work. In a fresh installation, "Secure iCal Port" is enabled by default.

I have also changed kopano-conderstart to do a proper condrestart i.e to only restart if the app is running. Formerly it just did a restart and there was a cron job in the background triggering this every night (among other things) so it was impossible for anyone to shutdown Kopano or any of its features for more than a day!

If you want to try a fresh installation, place and edit the files as before then do a:

yum install app-kopano* --enablerepo=Kopano-Core,z-push,Kopano-Webapp --nogpgcheck

Note I am doing a --nogpgcheck as I can't get the webapp key to work for the moment.

***** Hmm. I tried updating the attachment. I could delete it but can't re-add it. Please wait for an update. *****


I have some updated files to test a full upgrade to Kopano 8.7.5.0 and z-push to 2.5. App-kopano goes to 2.3.16. Anyone with a valid Kopano licence can test. Without a valid licence you cannot pull the updates from the Kopano repo.

I posted earlier today but have just bumped the app-kopano for a minor fix.

If you would like to test, unzip the attached kopano.zip file and place the kopano.repo file in /etc/yum.repos.d. Then edit the repo file, replacing "YOURSERIALNUMBER" with your serial number that you should be able to find from your Webconfig.

Place the two rpm's in a folder of your choice then, in ssh, navigate to that folder and run:

yum update app-kopano* --enablerepo=Kopano-Core,z-push

In the Webconfig, you can now set a port to and it will disable the service.

You will find in the webconfig that the "Secure iCal Port" is blank. This is because, although it shows as 8443 with Kopano 8.5.8, it is actually disabled due to another pref and the certificates are not set up to enable it to work. In 8.7.5 upgrade, I have set up the certificates to work but not enabled it as this, in effect, changes a current preference which the user may not want to do. If you want to enable "Secure iCal Port", just set it to 8443 or a port of your choice and it should work. In a fresh installation, "Secure iCal Port" is enabled by default.

I have also changed kopano-conderstart to do a proper condrestart i.e to only restart if the app is running. Formerly it just did a retsart and there was a cron job in the background triggering this every night (among other things) so it was impossible for anyone to shutdown Kopano or any of its features for more than a day!.

I have not yet tested a fresh installation, only an upgrade.

I have also not tested the Webapp upgrade, but you should be able to test with:

yum update kopano-webapp* --enablerepo=Kopano-Webapp

Post deleted so the wrong files can't be downloaded

Patrick de Brabander wrote:
Since you try to run the updates through the Clear repos, it is possible to make a dependency which update the kopano-condrestart script ?

I've already checked in the change. The /usr/sbin/kopano-condrestart script belongs to app-kopano which is the ClearOS app I need to update for the webconfig (done) and the update script (started on). The update script is the bit which will change the old cfg parameters to the new ones and fix some of the other issues I've found such as the certificate permissions. I will also need to do the install script for a fresh installation.

Nick Howitt wrote:

Slight bad news for you.

You = Me

Since you try to run the updates through the Clear repos, it is possible to make a dependency which update the kopano-condrestart script ?

Slight bad news for you. 8.5.8 came with both systemd unit files and sysvinit init files for starting kopano hence the difference in behaviour (seeing the green OK with the service command). 8.7.5 only comes with systemd unit files so the green OK disappears.

Also in kopano-condrestart, the condrestart needs to be changed to restart to maintain the same behaviour as before of always restarting the apps whether they are started or not. I am not going to rename the file to kopano-restart or I'd have to find where it is used (unless my arm is twisted).

All the systemctl documentation seems to say:

systemctl condrestart X

is directly equivalent to:

service X condrestart

It does not appear to be the case

The "service X condrestart" command run on a systemctl unit file will start the program if it is not running, however the "systemctl condrestart X" won't. I suspect this is buggy implementation of sysvinit -> systemd conversion upstream so I'll stick with the "service" command so as to not change the behaviour. The risk then, is an upstream change to rectify this behaviour.

Nick Howitt wrote:

Have you checked that all cfg files exist?

That was the trick.

I missed dagent.cfg, monitor.cfg, presence.cfg, search,cfg, spooler.cfg and unix.cfg
Don not know which was the problem and why they were not there.
Copied from other install and it is working.

Have you checked that all cfg files exist?

Nick Howitt wrote:

Attached are my three files but with the original lines commented out rather than removed - if the forum accepts zip files.

Thanks, but no difference.
Looks like it is in ical.cfg or gateway.cfg ?

Attached are my three files but with the original lines commented out rather than removed - if the forum accepts zip files.

Nick Howitt wrote:

That error will only happen if either you have not changed _port to _listen in line 119 of both files, or you have not added the new xxxx_listen parameters to your gateway.cfg and ical.cfg files.

In the ical.cfg were indeed not the new parameters.
I've added those, but or now getting error : File not found.

That error will only happen if either you have not changed _port to _listen in line 119 of both files, or you have not added the new xxxx_listen parameters to your gateway.cfg and ical.cfg files.

And no, I'm afraid I can't look at the backup location. It is rather beyond my skill set. I am not a PHP programmer at all but can do very minor things because of general coding knowledge. If they don't work, I don't know how to debug. If anyone wants to try it, there is a section of code in app-storage which may be usable.

Nick,

I applied the changes to Kopano_Gateway.php and Kopano_iCal.php, but no change in the webconfig menu.
Maybe I missed something ?

Can you also look into the backup path (/usr/clearos/apps/kopano_basic/libraries/Kopano_Basic.php) ;-)

If you want to enter a blank port to disable it, make the following changes:
/usr/clearos/apps/kopano/controllers/kopano_settings.php
Change TRUE to FALSE on lines 126 to 131

/usr/clearos/apps/kopano/libraries/Kopano_iCal.php
Change the line added:

        $port = "*:".$port;

to:

        if ( ! empty($port)) 

            $port = "*:".$port;

and in the same file change line 211 from:

        if (! Network_Utils::is_valid_port($port))

to:

        if (( ! empty($port)) and (! Network_Utils::is_valid_port($port)))

/usr/clearos/apps/kopano/libraries/Kopano_Gateway.php
Repeat the changes made to Kopano_Ical.php. Change the line added:

        $port = "*:".$port;

to:

        if ( ! empty($port)) 

            $port = "*:".$port;

and in the same file change line 211 from:

        if (! Network_Utils::is_valid_port($port))

to:

        if (( ! empty($port)) and (! Network_Utils::is_valid_port($port)))

Abandoning the Search error for the moment (I'm posting to the Kopano forums), I think I have the webconfig working. The following changes are needed:
/usr/clearos/apps/kopano/libraries/Kopano_Gateway.php
At line 119 change:

        $port = $file->lookup_value("/^${service}_port\s*=\s*/i");

        $port = trim($port);

to:

        $port = $file->lookup_value("/^${service}_listen\s*=\s*/i");

        $port = preg_replace('/.*:/', '', trim($port));

And at line 162 change:

        $key = $service . '_port';

to:

        $key = $service . '_listen';



        $port = "*:".$port;

/usr/clearos/apps/kopano/libraries/Kopano_Ical.php
The changes here are the same. At line 119 change:

        $port = $file->lookup_value("/^${service}_port\s*=\s*/i");

        $port = trim($port);

to:

        $port = $file->lookup_value("/^${service}_listen\s*=\s*/i");

        $port = preg_replace('/.*:/', '', trim($port));

And at line 162 change:

        $key = $service . '_port';

to:

        $key = $service . '_listen';



        $port = "*:".$port;

I've not tested the effect on the original line 168 in Kopano_Gateway.php and Kopano_Ical.php as it seems irrelevant. If the parameters are missing in the cfg files the webconfig fails anyway which is what we have been seeing when we commented out the values pop3_port etc.

It would seem to me to be relatively easy to also accept a blank value as well if you want to disable the port. A blank port would also need to be allowed in the port number validation validate_port(). The function set_port() would need to be changed to prepend the string "*:" to the port number only if the port number were not blank. This would be done to the $port line I added.

Nick Howitt wrote:

/usr/sbin/kopano-condrestart needs to be rewritten for systemd:

#!/bin/sh



/usr/bin/systemctl condrestart kopano-dagent

/usr/bin/systemctl condrestart kopano-server

/usr/bin/systemctl condrestart kopano-gateway

/usr/bin/systemctl condrestart kopano-ical

/usr/bin/systemctl condrestart kopano-monitor

/usr/bin/systemctl condrestart kopano-spooler



/usr/bin/systemctl condrestart kopano-search

/usr/bin/systemctl condrestart httpd

kopano-indexer no longer exists.

It is worth noting that the httpd restart is slow but it was not restarting before at all as /etc/init.d/httpd did not exist.

Correct. Good point.
The advantage of Service instead of Systemctl is that you see the progress during the execution of kopano-condrestart

Nick Howitt wrote:

I **think** I agree that it is working as I do see all the users' index folders under /var/lib/kopano/search and the folders are populated differently, presumably depending on how much mail there is. I may post to the Kopano forum about the startup error.

Same on my system.
Folders are filled and updated

/usr/sbin/kopano-condrestart needs to be rewritten for systemd:

#!/bin/sh



/usr/bin/systemctl condrestart kopano-dagent

/usr/bin/systemctl condrestart kopano-server

/usr/bin/systemctl condrestart kopano-gateway

/usr/bin/systemctl condrestart kopano-ical

/usr/bin/systemctl condrestart kopano-monitor

/usr/bin/systemctl condrestart kopano-spooler



/usr/bin/systemctl condrestart kopano-search

/usr/bin/systemctl condrestart httpd

kopano-indexer no longer exists.

It is worth noting that the httpd restart is slow but it was not restarting before at all as /etc/init.d/httpd did not exist.

I **think** I agree that it is working as I do see all the users' index folders under /var/lib/kopano/search and the folders are populated differently, presumably depending on how much mail there is. I may post to the Kopano forum about the startup error.

Nick Howitt wrote:

Have you ever had your kopano-search working? I've no idea what it is meant to do for the moment,This is both with 8.5.8 and 8.7.5. I have a feeling it has not been configured properly. Something else to test.

Yes. Kopano-search is working (running), but i also have the same errors in the log
Kopano-search

The kopano-search daemon is used to index all messages for all users in the kopano-server.

       Indexing messages greatly enhances the search performance of the kopano-server.



       After starting, the search daemon will continuously update the store index files and will

       keep listening for connections on the configured TCP port and/or Unix socket for search

       requests from the kopano-server

 service kopano-search status

kopano-search ● kopano-search.service - Kopano Core Search Engine

   Loaded: loaded (/usr/lib/systemd/system/kopano-search.service; enabled; vendor preset: disabled)

   Active: active (running) since Sun 2019-08-25 05:05:18 CEST; 3h 10min ago

     Docs: man:kopano-search(8)

           man:kopano-search.cfg(5)

 Main PID: 21313 (kopano-search)

   CGroup: /system.slice/kopano-search.service

           ├─21313 /bin/python2 /usr/sbin/kopano-search -F

           ├─21324 /bin/python2 /usr/sbin/kopano-search -F

           └─21325 /bin/python2 /usr/sbin/kopano-search -F

Not sure how to test this package. Searching in webapp is working

Have you ever had your kopano-search working? I've no idea what it is meant to do for the moment, but in my logs I always get:

2019-08-18 05:05:08,132 - search - ERROR - Traceback (most recent call last):

  File "/usr/lib/python2.7/site-packages/kopano/log.py", line 89, in log_exc

    try: yield

  File "/usr/lib/python2.7/site-packages/kopano_search/__init__.py", line 382, in incremental_sync

    new_state = self.server.sync(importer, self.state, log=self.log)

  File "/usr/lib/python2.7/site-packages/kopano/server.py", line 710, in sync

    return _ics.sync(self, self.mapistore, importer, state, log or self.log, max_changes, window=window, begin=begin, end=end, stats=stats)

  File "/usr/lib/python2.7/site-packages/kopano/ics.py", line 215, in sync

    exporter.Config(stream, flags, importer, restriction, None, None, 0)

  File "/usr/lib/python2.7/site-packages/MAPICore.py", line 1342, in Config

    def Config(self, *args): return _MAPICore.IExchangeExportChanges_Config(self, *args)

MAPIErrorNetworkError: MAPI error 80040115 (MAPI_E_NETWORK_ERROR)

This is both with 8.5.8 and 8.7.5. I have a feeling it has not been configured properly. Something else to test.

Beats head against the brick wall. RTFM helps.

To install z-push you do:

yum install z-push-common z-push-config-apache z-push-backend-kopano z-push-ipc-sharedmemory

.... and not what I did. Now it all works.

There seems to be no need to make any edits to USE_FULLEMAIL_FOR_LOGIN and all the default settings work, although changing:

define('TIMEZONE', '');

to

define('TIMEZONE', date_default_timezone_get());

as in the zarafa-z-push config reduces the apache warnings.

Can you post .conf of z-push and kopano.

Yum always removes dependencies so:

rpm -e --nodeps zarafa-z-push

Unfortunately the upgrade of z-push has been fatal and Outlook can no longer contact the server - Outlook is in the UK, the server is in Utah connected by VPN. The setting of "USE_FULLEMAIL_FOR_LOGIN" makes no difference (and was set to true with zarafa-z-push and worked OK).

The old and new configuration files are pretty much the same so I'll need to do some more troubleshooting but the logs are not giving any clues.

Nick Howitt wrote:

I think you mean without dependencies! Just trying it and the dependencies are app-kopano, app-kopano-basic, app-kopano-basic-core and app-kopano-core. I'm pretty certain I don't want to remove them!

Yep.
I thought it was like this

Yum remove app-zarafaz-push —nodeps

I think you mean without dependencies! Just trying it and the dependencies are app-kopano, app-kopano-basic, app-kopano-basic-core and app-kopano-core. I'm pretty certain I don't want to remove them!

Nick Howitt wrote:

@Patrick,
Did you have to uninstall zarafa-z-push before installing z-push-kopano? It seems that the z-push-kopano is not obsoleting zarafa-z-push.

Yes. I did an uninstall with dependencies

@Patrick,
Did you have to uninstall zarafa-z-push before installing z-push-kopano? It seems that the z-push-kopano is not obsoleting zarafa-z-push.

More stuff relating to the upgrade:

• The upgrade to utf-8 went fine
  
• As you noted in another thread, in ldap.cfg, ldap_host, ldap_port and ldap_protocol are now deprecated and should be replaced by ldap_uri e.g “ldap_uri = ldap://localhost:389/”. They do keep working for now but we should probably make the change. This can be scripted.
  

Just going to do the z-push upgrade now.

in /etc/z-push/z-push.conf.php

    /*

     * Whether to use the complete email address as a login name

     * (e.g. user@company.com) or the username only (user).

     * This is required for Z-Push to work properly after autodiscover.

     * Possible values:

     *   false - use the username only.

     *   true  - string the mobile sends as username, e.g. full email address (default).

     */

    define('USE_FULLEMAIL_FOR_LOGIN', false);

Nick Howitt wrote:
Patrick, can you remind me of the field which needed to be changed in the configuration so it just read the username and not the full e-mail address?

Nick,

in /etc/kopano/server.cfg

# Loginname format (for Multi-tenancy installations)

# When the user does not login through a system-wide unique

# username (like the email address) a unique name is created

# by combining the username and the tenantname.

# With this configuration option you can set how the

# loginname should be built up.

#

# Note: Do not use the = character in the format.

#

# Allowed variables:

#  %u Username

#  %c Teantname 

#

# default: %u

loginname_format = %u

I expect this is what you are looking for

I've tried an update to Kopano (so not the Webapp or z-push yet) on a VM and I've found the following:

• The initial installation was missing php-soap and php-mbstring which stopped z-push from working. Installing them and restarting httpd fixed it.
  
• server.cfg has four obsolete parameters, but they don't matter as we do not specify them so the defaults are used
  
• All the userscripts (e.g.createuser) have moved from /etc/kopano/userscripts to /usr/lib/kopano/userscripts so the entries in server.cfg need updating. Probably a better idea than moving the scripts.
  
• ical.cfg has 4 obsolete parameters which need to be changed as noted by Patrick, but note that icals never worked as it was set to disable to enable it you also have to set ssl_private_key_file and ssl_certificate_file. I used the values from gateway.cfg. This still had another issue. See next point.
  
• Kopano could never read the certificates as presented for icals, imaps and pop3s as they had root:root ownership and 0700 permissions. kkopano was unable to read the files as it runs as user kopano. You can set the permissions to 0744, but, perhaps better is to change the ownership to root:ssl-cert, permissions to 0740 and add kopano to the ssl-cert group.
  
• gateway.cfg had 8 obsolete parameters as noted by Patrick
  
• The webconfig will need updating to allow reading the new parameters in gateway.cfg and ical.cfg. The fields change from just being a straight port value to being ip:the_port but the ip can be defaulted to *, so "*:110" for pop3 etc.
  
• Optionally the webconfig could be changed to allow a blank port to write a blank value to the parameter to disable the setting, or some other method used to disable the setting. This is not currently done in the webconfig so could be skipped.
  
• All the changes to the parameters and sorting out the certificates could be scripted in a deploy/upgrade routine in the webconfig.
  

I still need to do some proper testing, then move onto z-push.

Patrick, can you remind me of the field which needed to be changed in the configuration so it just read the username and not the full e-mail address?

Nick Howitt wrote:

Hello Patrick, please correct me if I'm wrong, but the latest released version I can see in Kopan's portal is 8.7.3.0_0+3. 8.7.5.0_0+43 seems to only be an RC with a TBD release date.

Hi Nick,

Correct. Latest stable version is 8.7.3.
For Webapp 3.5.8.2358-99.1 and Z-push 2.5.0+0

Hello Patrick, please correct me if I'm wrong, but the latest released version I can see in Kopan's portal is 8.7.3.0_0+3. 8.7.5.0_0+43 seems to only be an RC with a TBD release date.

Nick Howitt wrote:

Hmm. Those port changes may be a mess as that is where I would expect the webconfig to write to. This is why kopano packaging is a mess. They keep changing things. We'd need to see where the new values go and update the webconfig accordingly.

Kopano has indeed changed the names

https://documentation.kopano.io/kopano_changelog/kc.html#kopano-core-8-7-5-final-8-7-5-0

server.cfg



The following options are deprecated: - server_ssl_enabled - server_ssl_port - server_tcp_enabled - server_tcp_port



The above options have been replaced with (these options were already available in Kopano Groupware Core 8.6.x): - server_listen - server_listen_tls



ical.cfg



The following options are deprecated: - ical_enable - icals_enable - ical_port - icals_port



The above options have been replaced with: - ical_listen - icals_listen



gateway.cfg



The following options are deprecated: - imap_enable - imaps_enable - imap_port - imaps_port - pop3_enable - pop3s_enable - pop3_port - pop3s_port



The above options have been replaced with: - pop3_listen - pop3s_listen - imap_listen - imaps_listen

I will try to change these names and test

It looks like just a text adjustment in COS app

pop3_port = 110
to
pop3_listen = *:110

Nick Howitt wrote:

Hmm. Those port changes may be a mess as that is where I would expect the webconfig to write to. This is why kopano packaging is a mess. They keep changing things. We'd need to see where the new values go and update the webconfig accordingly.

Kopano is reducing the options in the config files. Do not know why, but i believe to make it simple

Hmm. Those port changes may be a mess as that is where I would expect the webconfig to write to. This is why kopano packaging is a mess. They keep changing things. We'd need to see where the new values go and update the webconfig accordingly.

Hi,

I've tried update Kopano-core through the Kopano repos.
Kopano server is running and receiving and sending is possible with the current mailboxes/users.

Creating a new user gives the following error

Command "/etc/kopano/userscripts/createuser" exited with non-zero status 127

The directory /etc/kopaono/userscript is missing (deleted)
Copying the directory back (backup) and setting the correct permission solves the issue

The following services will not start :

Kopano iCal Gateway
Kopano POP/IMAP Gateway


Kopano gateway

Jul 18 18:36:31 xxxxxx.nl kopano-gateway[3940]: [crit   ] Config error: Unknown option "pop3s_enable" found!

Jul 18 18:36:31 xxxxxx.nl kopano-gateway[3940]: [crit   ] Config error: Unknown option "pop3s_port" found!

Jul 18 18:36:31 xxxxxx.nl kopano-gateway[3940]: [crit   ] Config error: Unknown option "imap_enable" found!

Jul 18 18:36:31 xxxxxx.nl kopano-gateway[3940]: [crit   ] Config error: Unknown option "imap_port" found!

Jul 18 18:36:31 xxxxxx.nl kopano-gateway[3940]: [crit   ] Config error: Unknown option "imaps_enable" found!

Jul 18 18:36:31 xxxxxx.nl kopano-gateway[3940]: [crit   ] Config error: Unknown option "imaps_port" found!

Jul 18 18:36:31 xxxxxx.nl kopano-gateway[3940]: /usr/sbin/kopano-gateway: Startup failed: call failed (80004005). Please check the logfile (/var/log/kopano/gatewa...r details.

Putting # in the following lines in /etc/kopano/gateway.cfg solves the issue

# enable/disable POP3, and POP3 listen port

#pop3_enable	=	yes

#pop3_port	=	110



# enable/disable Secure POP3, and Secure POP3 listen port

#pop3s_enable	=	yes

#pop3s_port	=	995



# enable/disable IMAP, and IMAP listen port

#imap_enable	=	yes

#imap_port	=	143



# enable/disable Secure IMAP, and Secure IMAP listen port

#imaps_enable	=	yes

#imaps_port	=	993

Kopano ical

Jul 18 18:43:37 xxxxxx.nl kopano-ical[4872]: [crit   ] Config error: Unknown option "ical_enable" found!

Jul 18 18:43:37 xxxxxx.nl kopano-ical[4872]: [crit   ] Config error: Unknown option "ical_port" found!

Jul 18 18:43:37 xxxxxx.nl kopano-ical[4872]: [crit   ] Config error: Unknown option "icals_enable" found!

Jul 18 18:43:37 xxxxxx.nl kopano-ical[4872]: [crit   ] Config error: Unknown option "icals_port" found!

Putting # in the following lines in /etc/kopano/gateway.cfg solves the issue

# whether normal connections can be made to the ical server

#ical_enable = yes



# port which the ical server listens on for normal connections

#ical_port = 8008



# whether ssl connections can be made to the ical server

#icals_enable = no



# port which the ical server listens on for ssl connections

#icals_port = 8443

These changes wil break with the app-kopano from COS.

Thanks for that. I've updated the instructions to also cover zarafa-z-push.

Nick, I performed all of the steps you identified above to comply with the CVE. The Kopano system successfully upgraded to 8.5.8.2. That said, "yum info zarafa-z-push" reports 2.2.13 and not 2.3.9.

What did I do wrong?

Edit: I ran the beta upgrade for "*zarafa-z-push*" and this got me to 2.3.9.

Good news! Thank you! Now to work on the Kopano OL link.

It is a bit more complicated than that. An announcement was made on the forum a long time ago, but it looks like the take up was pretty poor so Clearcenter are going to have to contact everyone with a subscription. You will need to manually upgrade because of a CVE. The process is laid out here. If you do this you will get z-push 2.3.9. Please don't just do the update without doing the rest of the post.

Has this topic been reviewed? I was hoping to use Kopano Outlook Extension but it requires Z-Push 2.3.x. The base install is 2.2.13.

That seems pretty simplistic considering the steps I had to take to update Kopano as given me by the Clear Center team. It wasn't a simple yum update after enabling a repository.

Hmm. I'd be wary of that as I think the main package is specially built by Clearcenter for ClearOS to integrate with LDAP among other things. I'll see if I can ask Ben if I get to chat to him.