After upgrade to 8.2.0: "Cannot connect to Kopano Core."
after following the instructions in the Kopano UCS Wiki I did inadvertently upgrade Kopano to 8.2.0 together with UCS.
I’ve read the changelog (especially the need for a certificate chain matching the hostname) and because of this I initially wanted to postpone the Kopano upgrade. Anyways, now it has happened, it seemed to work at first and I don’t have any VM Snapshot anymore. So I’ve got to deal with it.
The problem is, that I have a somewhat working connection over ActiveSync/Z-Push (Mobile Phones and Outlook), but I can’t connect to Kopano through Web- or Deskapp:
Cannot connect to Kopano Core.
Which server logs do we need to diagnose the problem?
Hello @HPH_ZForum ,
like already said in https://forum.kopano.io/topic/66/kopano-core-8-2-0-final-is-now-available/25 the ssl changes not relevant in the default configuration of Univention.
Since Z-Push continued to work it seems the socket setting for the WebApp seems off. You can issue the following command to set it to its default:
ucr set zarafa/webapp/config/DEFAULT_SERVER="\"default:\""
sorry for the delay, there was a tragic case at one of our partner organizations and we had to help out as good as we could.
The Problem is not solved, and I can’t find any helpful information inside the logs.
Where exactly do I have to look?
Hi @HPH_ZForum ,
in that case I would suggest to get in contact with our support to have a direct look at your system.
now I’ve found a single line in server.log after trying to login:
Wed Apr 5 19:12:59 2017: [warning] SSL_accept() failed in soap_ssl_accept()```
r100gs last edited by
I installed Kopano 8.2.0 on Univention Server.
Everything was working fine until restart off server.
Now I cannot log into webapp.
Z-Push is working fine, so I get emails on my android phone.
@r100gs you would need to supply some more information if you expect helpful answers.
just to mention:
uninstalling and reinstalling WebApp did not help.
At the moment I have no clue on where to look.
I’d prefer not to use the support through your partner (we’ve got the “basic” license only on this site), could you please give me some advise on where to look in the logs to find out what’s going wrong specifically?
Hi @HPH_ZForum ,
thats the problem. I am not quite sure where the error lies, thats why I suggested that someone from our support has a look on your system. If you don’t want to go through your partner, you can still open a support case through https://portal.kopano.com/.
@fbartels got it. I’ve opened support case KS-37494. Let’s see how it goes!
Thanks and BR,
r100gs last edited by
sorry about the delay.
I think in my case it has nothing to do with the LE-certificate
Meanwhile I reinstalled the server several times. And in the beginning everything works fine. With and without LE-certtificate but after restart the kopano webapp is not able to connect to mysql according to the server.log
Thu Apr 20 15:43:38 2017: [crit ] Unable to connect to database: Can't connect to MySQL server on '127.0.0.1' (111) Thu Apr 20 15:43:38 2017: [ notice] Server shutdown complete. Thu Apr 20 16:02:14 2017: [ notice] Starting server version 8,2,1,530, pid 2684 Thu Apr 20 16:02:15 2017: [error ] ECDatabaseMySQL::Connect(): mysql connect fail: Can't connect to MySQL server on '127.0.0.1' (111) Thu Apr 20 16:02:15 2017: [crit ] Unable to connect to database: Can't connect to MySQL server on '127.0.0.1' (111) Thu Apr 20 16:02:15 2017: [ notice] Server shutdown complete. Thu Apr 20 16:25:13 2017: [ notice] Starting server version 8,2,1,530, pid 2632 Thu Apr 20 16:25:14 2017: [error ] ECDatabaseMySQL::Connect(): mysql connect fail: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Thu Apr 20 16:25:14 2017: [crit ] Unable to connect to database: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Thu Apr 20 16:25:15 2017: [ notice] Server shutdown complete.
I tried to edit /etc/mysql/my.conf like this
# Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. #bind-address = 127.0.0.1
so it should be able to connect to mysql from every server.
But no effect
Is it possible that kopano server starts before mysql is started?
the mysql error.log shows
170420 16:24:45 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and$ 170420 16:24:45 [Note] Plugin 'FEDERATED' is disabled. 170420 16:24:47 InnoDB: The InnoDB memory heap is disabled 170420 16:24:47 InnoDB: Mutexes and rw_locks use GCC atomic builtins 170420 16:24:47 InnoDB: Compressed tables use zlib 1.2.7 170420 16:24:47 InnoDB: Using Linux native AIO 170420 16:24:47 InnoDB: Initializing buffer pool, size = 128.0M 170420 16:24:47 InnoDB: Completed initialization of buffer pool 170420 16:24:48 InnoDB: highest supported file format is Barracuda. 170420 16:25:24 InnoDB: Waiting for the background threads to start 170420 16:25:25 InnoDB: 5.5.54 started; log sequence number 9076131 170420 16:25:25 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306 170420 16:25:25 [Note] - '0.0.0.0' resolves to '0.0.0.0'; 170420 16:25:25 [Note] Server socket created on IP: '0.0.0.0'. 170420 16:25:27 [Note] Event Scheduler: Loaded 0 events 170420 16:25:28 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.5.54-0.A~22.214.171.124703071716' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Univention)
So i think its running?
but systemctl status mysql
shows that it is nor running?
I dont know what to do.
Hi @r100gs ,
ah that is something that also already came up in https://help.univention.com/t/fehler-nach-upgrade-4-2-kopano-startet-nicht-mehr/5444. Up until now I was not able to reproduce this here locally, but I also only have fresh 4.2 systems and none that are upgraded from 4.1.
EDIT: but if kopano-server did not start, then you actually should not be able to connect through z-push as well…
H.-P. Stradinger had a look at the config and it seems like
# Warning: the value "DEFAULT_SERVER" has been set via UCR variable "kopano/webapp/config/DEFAULT_SERVER" //define("DEFAULT_SERVER","https://ucs.domain.local:237/zarafa"); define("DEFAULT_SERVER", "file:///var/run/kopano/server.sock");
the now commented UCR variable was the culprit.
The connection works flawlessly now.
My question is: what is the correct UCR setting?
@HPH_ZForum yes, he updated me internally as well about this. And now I also know why the command I gave you above did not work, it was still for Zarafa…
ucr set kopano/webapp/config/DEFAULT_SERVER="\"default:\""
would have been the right one.
@fbartels sure, I could have seen that as well… :face_palm:
r100gs last edited by r100gs
Seems to work now! I was a little bit silly, but now I put in
an its running!
THX for the great help!