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.