Socket permissions issues with kopano-server build 8.7.81.162

jengelh

@thctlo said in Socket permissions issues with kopano-server build 8.7.81.162:

@jengelh i think that that “panic” part is totaly right.
The problem is the errors trow you off and you searching to fix this first, goes in the wrong direction.

Panicing over a lost -F option is the silliest thing I’ve heard.

micro

I am running into the same issue as explained here on this thread. Yesterday I upgraded to 8.7.81.164 on Debian Stretch and the server socket was not accessible from the other Kopano services. When I

cd /var/run/kopano && chown kopano. server.sock prio.sock

after (!) and kopano-server is already running it seems that the services work fine because spooler and dagent are not reporting the usual gsoap() connection failures. But I still cannot logon through WebApp, I get the error

Cannot connect to Kopano Core

I can run

kopano-admin -l

successfully though. Running

z-push-top

also doesn’t show any activity, no device/user shown here although configuration is double-checked. Smartphones cannot sync any more. The kopano logs don’t show any related warnings or errors. Any clues where to look at?

micro

anyone ? my whole Kopano mail system is down, I cannot make use of it. I really don’t want to start mess around with downgrading. Any help or hint appreciated.

EDIT: after lot of trial & error I did find following workaround. For anyone experiencing the same issue, here’s some information:

First of all I modified “/etc/kopano/webapp/config.php” and changed from socket to https.
before ==> define(“DEFAULT_SERVER”, “file:///var/run/kopano/server.sock”);
after ==> define(“DEFAULT_SERVER”, “https://localhost:237/”);

After this change Kopano-WebApp login works successfully ! That indicated that the issue indeed lies in server socket. So …

… I reverted this modification to the original state (using the server socket) and then I checked the file permissions on the server socket file “/var/run/kopano/server.sock” and “/var/run/kopano/prio.sock” As suggested initially in this thread I just changed owner+group to “kopano”. The files looked like that:

srwxr-xr-x 1 kopano kopano 0 Jun 25 14:35 /var/run/kopano/prio.sock
srwxr-xr-x 1 kopano kopano 0 Jun 25 14:35 /var/run/kopano/server.sock

But this was not enough as WebApp requires write access to this socket file and that’s why all the thing didn’t work. After adding the write permission to others it works like a charm. The files now look like that:

srwxr-xrwx 1 kopano kopano 0 Jun 25 14:35 /var/run/kopano/prio.sock
srwxr-xrwx 1 kopano kopano 0 Jun 25 14:35 /var/run/kopano/server.sock

This is just a workaround and certainly Kopano will provide a patch soon.

fbartels

@micro said in Socket permissions issues with kopano-server build 8.7.81.162:

anyone ? my whole Kopano mail system is down, I cannot make use of it. I really don’t want to start mess around with downgrading. Any help or hint appreciated

Your signature still lists one of our supported versions but this issue only occurs in our nightly downloads. I am wondering why you are now using these. Did you stop with your subscription?

For production deployments it’s always recommended to use our supported packages. And if an issue occurs you have direct contact with our support.

Part of these nightly downloads (if your really want to use them instead) is that you should be doing extensive testing before upgrading your installation as breakage will occurs in these packages at any time.

micro

Felix no. My signature is still valid and is showing the configuration of our company setup. My posting here refers to the community edition which I use for private use at home. That’s why I was calm even when my mail server was down for >24h ;) but I am happy that I have access to my mails/calendar/contacts again until this get fixed with a patch.

thctlo

Hai,

Small update on this.

I’ve updated today from 8.7.81.151.4eaf3e0cf-0+249.1 to 8.7.81.203.1889fded5-0 and today i’m happy to say, i have had zero problems with this update.

i have only one suggestion.
libgsoap-kopano-2.8.84 was not removed after the install of libgsoap-kopano-2.8.86

Just an suggestion here.
If you change the packaging numbers then this is also nicely upgraded.
for example from libgsoap-kopano-2.8.86 to libgsoap-kopano-2.8-86~0+1.1
Or create a meta package which does the remove of the older version.

jengelh

If you change the packaging numbers then this is also nicely upgraded.
for example from libgsoap-kopano-2.8.86 to libgsoap-kopano-2.8-86~0+1.1
Or create a meta package which does the remove of the older version.

(I’ll read that as 2.8.84 -> 2.8.86)
Packaging systems have a hardremoval instruction (Obsoletes in rpm, Replaces in deb), but they are prone to cascading effects. Just think of all the breakage if qt5 were marked as replacing qt4, it would either lead to removal of all qt4-requiring apps, or block the installation of qt5.

A weakremoval instruction is the way, but, as far as I know, only openSUSE has such.

sbauhaus

Hi,
sorry for using this old thread but is this problem resolved?
I am on kopano-server 8.7.84.133.fdc228634 and have to change the socket owner after every reboot of the server.

Thanks.

Greetings
Sebastian

fbartels

Hi @sbauhaus,

the issue came back a while ago, but has since been resolved.

jengelh

Fix was included in kopanocore-8.7.84-140-g5f74297a5 .