Hi,
For those who are interested you can update Webapp and Z-push with the Kopano repositories.
webapp.repo
z-push.repo
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
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:[email protected]/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:[email protected]/supported/core:/final/RHEL_7/
gpgcheck=1
gpgkey=https://serial:[email protected]/supported/core:/final/RHEL_7/repodata/repomd.xml.key
enabled=1
In Kopano Basic
Share this post:
Responses (78)
-
Accepted Answer
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. - The upgrade to utf-8 went fine
-
Accepted Answer
Patrick de Brabander wrote:
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.
Since you try to run the updates through the Clear repos, it is possible to make a dependency which update the kopano-condrestart script ? -
Accepted Answer
-
Accepted Answer
-
Accepted Answer
-
Accepted Answer
-
Accepted Answer
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. -
Accepted Answer
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. -
Accepted Answer
-
Accepted Answer
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
The directory /etc/kopaono/userscript is missing (deleted)Command "/etc/kopano/userscripts/createuser" exited with non-zero status 127
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. -
Accepted Answer
-
Accepted Answer
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 -
Accepted Answer
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 -
Accepted Answer
-
Accepted Answer
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 -
Accepted Answer
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 initial installation was missing php-soap and php-mbstring which stopped z-push from working. Installing them and restarting httpd fixed it.
-
Accepted Answer
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 -
Accepted Answer
in /etc/z-push/z-push.conf.php
/*
* Whether to use the complete email address as a login name
* (e.g. [email protected]) 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);
-
Accepted Answer
-
Accepted Answer
-
Accepted Answer
-
Accepted Answer
-
Accepted Answer
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. -
Accepted Answer
Beats head against the brick wall. RTFM helps.
To install z-push you do:
.... and not what I did. Now it all works.yum install z-push-common z-push-config-apache z-push-backend-kopano z-push-ipc-sharedmemory
There seems to be no need to make any edits to USE_FULLEMAIL_FOR_LOGIN and all the default settings work, although changing:
todefine('TIMEZONE', '');
as in the zarafa-z-push config reduces the apache warnings.define('TIMEZONE', date_default_timezone_get());
-
Accepted Answer
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:
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.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)
-
Accepted Answer
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 -
Accepted Answer
-
Accepted Answer
/usr/sbin/kopano-condrestart needs to be rewritten for systemd:
kopano-indexer no longer exists.#!/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
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. -
Accepted Answer
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 -
Accepted Answer
Nick Howitt wrote:
/usr/sbin/kopano-condrestart needs to be rewritten for systemd:
kopano-indexer no longer exists.#!/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
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 -
Accepted Answer
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:
to:$port = $file->lookup_value("/^${service}_port\s*=\s*/i");
$port = trim($port);
$port = $file->lookup_value("/^${service}_listen\s*=\s*/i");
$port = preg_replace('/.*:/', '', trim($port));
And at line 162 change:
to:$key = $service . '_port';
$key = $service . '_listen';
$port = "*:".$port;
/usr/clearos/apps/kopano/libraries/Kopano_Ical.php
The changes here are the same. At line 119 change:
to:$port = $file->lookup_value("/^${service}_port\s*=\s*/i");
$port = trim($port);
$port = $file->lookup_value("/^${service}_listen\s*=\s*/i");
$port = preg_replace('/.*:/', '', trim($port));
And at line 162 change:
to:$key = $service . '_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.$key = $service . '_listen';
$port = "*:".$port;
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. -
Accepted Answer
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:
to:$port = "*:".$port;
if ( ! empty($port))
$port = "*:".$port;
and in the same file change line 211 from:
to:if (! Network_Utils::is_valid_port($port))
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:
to:$port = "*:".$port;
if ( ! empty($port))
$port = "*:".$port;
and in the same file change line 211 from:
to:if (! Network_Utils::is_valid_port($port))
if (( ! empty($port)) and (! Network_Utils::is_valid_port($port)))
-
Accepted Answer
-
Accepted Answer
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. -
Accepted Answer
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. -
Accepted Answer
-
Accepted Answer
-
Accepted Answer
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.
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »