Forums

Resolved
0 votes
Hi,

For those who are interested you can update Webapp and Z-push with the Kopano repositories.

webapp.repo
[Kopano-Webapp]
name=Builds of final releases (RHEL_7)
type=rpm-md
baseurl=https://serial:YOURSERIALNUMBER@download.kopano.io/supported/webapp:/final/RHEL_7/
gpgcheck=1
enabled=1


z-push.repo
[z-push]
name=Z-Push noarch Enterprise Linux 7 - $basearch
baseurl=http://repo.z-hub.io/z-push:/final/RHEL_7
failovermethod=priority
enabled=1
gpgcheck=0


Not sure how this will effect the update coming through COS, but don't think it will have any influence.


I think the main Kopano packages could also be updated, but not yet tried....

kopano.repo
[Kopano-Core]
name=Builds of final releases (RHEL_7)
type=rpm-md
baseurl=https://serial:YOURSERIALNUMBER@download.kopano.io/supported/core:/final/RHEL_7/
gpgcheck=1
gpgkey=https://serial:YOURSERIALNUMBER@download.kopano.io/supported/core:/final/RHEL_7/repodata/repomd.xml.key
enabled=1
Saturday, December 08 2018, 06:39 PM
Share this post:
Responses (78)
  • Accepted Answer

    Saturday, December 08 2018, 10:11 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, December 12 2018, 04:39 AM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, March 19 2019, 11:09 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, March 20 2019, 08:06 AM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, March 20 2019, 06:45 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, March 20 2019, 08:23 PM - #Permalink
    Resolved
    0 votes
    Thanks for that. I've updated the instructions to also cover zarafa-z-push.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 18 2019, 04:45 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 18 2019, 05:21 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 18 2019, 07:47 PM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 18 2019, 08:12 PM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Monday, July 22 2019, 08:29 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 23 2019, 06:33 AM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 22 2019, 05:12 PM - #Permalink
    Resolved
    0 votes
    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?
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 22 2019, 05:34 PM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 22 2019, 05:38 PM - #Permalink
    Resolved
    0 votes
    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);
    The reply is currently minimized Show
  • Accepted Answer

    Friday, August 23 2019, 10:44 AM - #Permalink
    Resolved
    0 votes
    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.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Friday, August 23 2019, 10:54 AM - #Permalink
    Resolved
    0 votes
    @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.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, August 23 2019, 10:58 AM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Friday, August 23 2019, 11:02 AM - #Permalink
    Resolved
    0 votes
    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!
    The reply is currently minimized Show
  • Accepted Answer

    Friday, August 23 2019, 11:32 AM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Friday, August 23 2019, 11:41 AM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, August 23 2019, 02:57 PM - #Permalink
    Resolved
    0 votes
    Can you post .conf of z-push and kopano.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, August 23 2019, 03:01 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, August 23 2019, 03:46 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, August 25 2019, 06:13 AM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Monday, August 26 2019, 09:44 AM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, August 26 2019, 01:44 PM - #Permalink
    Resolved
    0 votes
    /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.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, August 26 2019, 02:54 PM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Monday, August 26 2019, 05:03 PM - #Permalink
    Resolved
    0 votes
    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
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 27 2019, 01:54 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 27 2019, 03:57 PM - #Permalink
    Resolved
    -1 votes
    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)))
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 27 2019, 07:20 PM - #Permalink
    Resolved
    0 votes
    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) ;-)
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 27 2019, 07:55 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 27 2019, 08:30 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 27 2019, 08:39 PM - #Permalink
    Resolved
    0 votes
    Attached are my three files but with the original lines commented out rather than removed - if the forum accepts zip files.
    Attachments:
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 27 2019, 08:45 PM - #Permalink
    Resolved
    0 votes
    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 ?
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 27 2019, 08:51 PM - #Permalink
    Resolved
    0 votes
    Have you checked that all cfg files exist?
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, August 27 2019, 08:57 PM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 29 2019, 07:50 AM - #Permalink
    Resolved
    0 votes
    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.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, August 29 2019, 10:11 AM - #Permalink
    Resolved
    0 votes
    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).
    The reply is currently minimized Show
Your Reply