Navigation

    Kopano
    • Register
    • Login
    • Search
    • Categories
    • Get Official Kopano Support
    • Recent
    Statement regarding the closure of the Kopano community forum and the end of the community edition

    Socket permissions issues with kopano-server build 8.7.81.162

    Kopano Groupware Core
    10
    20
    2045
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • jcmerg
      jcmerg last edited by jcmerg

      Hi,

      looks like there is a bug ore something else between kopano-server version 8.7.81.151 and 8.7.81.162.

      In version .151, /var/run/kopano/server.sock was created as kopano:kopano
      Since version .162 the socket was created as root:root and without any permissions

      This breaks dagent, z-push, etc. for me … Anyone else with similar issues ?

      chown kopano:kopano and chmod with right permissions fixes the issue … but the old behavior was definitely changed between this versions.

      1 Reply Last reply Reply Quote 1
      • umgfoin
        umgfoin last edited by umgfoin

        This is due to commit 5995dbf7cf8.

        chown kopano:kopano and chmod with right permissions fixes the issue … but the old behavior was definitely changed between this versions.

        Yes, but permissions will be reset on service-restart.

        I’ve created a PR fixing the problems, but it will need further review by kopano.

        As a first remedy, you can revert the above merge.
        ++umgfoin

        1 Reply Last reply Reply Quote 0
        • Fux
          Fux last edited by

          I got the same problems as the op - and many more:

          changing owner and group of the socket does not solve all connection problems. I had to switch to network communication (localhost:236) for dagent, search, webapp…

          Postfix and dagent didn’t communicate via socket either - had to switch to localhost:2003

          All deamons now start in some kind of foreground and don’t fork into background. This blocks startup of the hole server. I guess it’s because they are now only compatible with systemd and no other init-systems anymore. Sadly.

          kopano-search changed option for config-file from small letter “c” to capital “C”. Why this?

          kopano-dagent doesn’t know option “-d” anymore…

          I had to downgrade to 8.7.80 to get a working system.

          jengelh 1 Reply Last reply Reply Quote 1
          • jengelh
            jengelh Banned @Fux last edited by

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

            All deamons now start in some kind of foreground and don’t fork into background.

            As was documented in RELNOTES.txt.

            I guess it’s because they are now only compatible with systemd and no other init-systems anymore.

            You are incorrect. Even non-systemd systems have a way to background processes. The most trivial being the & character, which everyone using sh (a popular implementation of some init systems) should know about already.

            kopano-dagent doesn’t know option “-d” anymore…

            It had the same function as the absence of -F, so was practically useless. As there is no more self-backgrounding, -d has no meaning and had to be removed.

            Fux 1 Reply Last reply Reply Quote 0
            • dnns
              dnns last edited by

              I have got the same Problem. How to fix it? I used chmod to get it working until the next service restart.

              1 Reply Last reply Reply Quote 0
              • A Former User
                A Former User last edited by

                hi,

                prio.sock is also root:root

                does this also needs to be kopano:kopano?

                1 Reply Last reply Reply Quote 0
                • Fux
                  Fux @jengelh last edited by Fux

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

                  The most trivial being the & character, which everyone using sh (a popular implementation of some init systems) should know about already.

                  The problem with this (and with the background-option of start-stop-daemon) is: you don’t see any (error) outputs of the started process.

                  Just checked some init-scripts of other popular daemons (like postfix, samba, bind…): no one uses the "&"or the background-option of start-stop-daemon. I think there are still some good reasons for daemons to self fork into background (i.e. for having the return code in the start script and working with it).

                  jengelh 1 Reply Last reply Reply Quote 0
                  • A Former User
                    A Former User last edited by

                    webapp does not function either. after login it cannot connect to kopano core.

                    [Sun Jun 16 21:46:08.595819 2019] [:error] [pid 255] [client 192.168.2.6:50436] PHP Fatal error:  require_once(): Failed opening required '/usr/share/kopano-webapp/config.php' (include_path=':/usr/share/kopano/php') in /usr/share/kopano-webapp/server/includes/bootstrap.php on line 26
                    
                    
                    1 Reply Last reply Reply Quote 1
                    • jengelh
                      jengelh Banned @Fux last edited by

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

                      The problem with this (and with the background-option of start-stop-daemon) is: you don’t see any (error) outputs of the started process.

                      That does not seem so different from systemd, where systemctl start xyz generally also does not output any lines from the process (just the unit as a meta entity) and you need to go to journalctl or a logfile.

                      I think there are still some good reasons for daemons to self fork into background (i.e. for having the return code in the start script and working with it).

                      Except that such was never correctly implemented. kopano-server could fail after fork, but before reaching the mainloop, such as when the database schema upgrade went sour. Or when sockets/ports are already occupied. Or when mysql is down. Or your config file did not have the right incantations.

                      You are just making a panic for no reason.

                      1 Reply Last reply Reply Quote 0
                      • thctlo
                        thctlo last edited by thctlo

                        @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.

                        Every logrotate the rights are on socket files are rest to root:root
                        Tested this also with : .164 today on debian.
                        I saw the fix, so i’ll wait for the fix and reset the right every restart/reboot/start.

                        If one is using my get-community-packages script, with the enabled backup function, then it’s easy to revert back to .150.

                        remove the “amd64” folder with the latested community packages.
                        goto you backup folder, move the good version back and rename it back to amd64.

                        apt update
                        and install it again.

                        The remove and install blocks i used, on my Debian 9 server.

                        apt-get remove kopano-backup kopano-client kopano-common kopano-contacts kopano-dagent kopano-gateway kopano-ical kopano-lang kopano-monitor kopano-python-utils kopano-search kopano-server kopano-server-packages \
                          kopano-spamd kopano-spooler kopano-utils kopano-webapp kopano-webapp-plugin-desktopnotifications kopano-webapp-plugin-filepreviewer kopano-webapp-plugin-files kopano-webapp-plugin-filesbackend-smb \
                          kopano-webapp-plugin-folderwidgets kopano-webapp-plugin-htmleditor-minimal-tinymce kopano-webapp-plugin-htmleditor-quill kopano-webapp-plugin-intranet kopano-webapp-plugin-mdm \
                          kopano-webapp-plugin-pimfolder kopano-webapp-plugin-quickitems kopano-webapp-plugin-smime kopano-webapp-plugin-spell kopano-webapp-plugin-spell-en kopano-webapp-plugin-spell-nl \
                          kopano-webapp-plugin-titlecounter php7-mapi python3-kopano python3-kopano-search python3-kopano-utils python3-mapi z-push-backend-kopano z-push-kopano \
                          libkcarchiver0 libkcarchivercore0 libkcfreebusy0 libkcicalmapi0 libkcindex0 libkcinetmapi0 libkcpyplug0 libkcrosie0 libkcserver0 libkcsoap0 libkcutil0 libmapi1
                        

                        ( ! Note, if more is more is removed, just capture what is removed, so you can reinstall it again ).

                        apt-get install kopano-backup kopano-client kopano-common kopano-contacts kopano-dagent kopano-gateway kopano-ical kopano-lang kopano-monitor kopano-python-utils kopano-search kopano-server kopano-server-packages \
                          kopano-spamd kopano-spooler kopano-utils kopano-webapp kopano-webapp-plugin-desktopnotifications kopano-webapp-plugin-filepreviewer kopano-webapp-plugin-files kopano-webapp-plugin-filesbackend-smb \
                          kopano-webapp-plugin-folderwidgets kopano-webapp-plugin-htmleditor-minimal-tinymce kopano-webapp-plugin-htmleditor-quill kopano-webapp-plugin-intranet kopano-webapp-plugin-mdm \
                          kopano-webapp-plugin-pimfolder kopano-webapp-plugin-quickitems kopano-webapp-plugin-smime kopano-webapp-plugin-spell kopano-webapp-plugin-spell-en kopano-webapp-plugin-spell-nl \
                          kopano-webapp-plugin-titlecounter php7-mapi python3-kopano python3-kopano-search python3-kopano-utils python3-mapi z-push-backend-kopano z-push-kopano \
                          libkcarchiver0 libkcarchivercore0 libkcfreebusy0 libkcicalmapi0 libkcindex0 libkcinetmapi0 libkcpyplug0 libkcrosie0 libkcserver0 libkcsoap0 libkcutil0 libmapi1
                        
                        jengelh 1 Reply Last reply Reply Quote 0
                        • jengelh
                          jengelh Banned @thctlo last edited by

                          @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.

                          1 Reply Last reply Reply Quote 0
                          • micro
                            micro last edited by 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?

                            1 Reply Last reply Reply Quote 0
                            • micro
                              micro last edited by 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 1 Reply Last reply Reply Quote 0
                              • fbartels
                                fbartels Kopano @micro last edited by

                                @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.

                                Regards Felix

                                Resources:
                                https://kopano.com/blog/how-to-get-kopano/
                                https://documentation.kopano.io/
                                https://kb.kopano.io/

                                Support overview:
                                https://kopano.com/support/

                                1 Reply Last reply Reply Quote 0
                                • micro
                                  micro last edited by

                                  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.

                                  1 Reply Last reply Reply Quote 0
                                  • thctlo
                                    thctlo last edited by

                                    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 1 Reply Last reply Reply Quote 0
                                    • jengelh
                                      jengelh Banned @thctlo last edited by

                                      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.

                                      1 Reply Last reply Reply Quote 0
                                      • sbauhaus
                                        sbauhaus last edited by

                                        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 1 Reply Last reply Reply Quote 0
                                        • fbartels
                                          fbartels Kopano @sbauhaus last edited by

                                          Hi @sbauhaus,

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

                                          Regards Felix

                                          Resources:
                                          https://kopano.com/blog/how-to-get-kopano/
                                          https://documentation.kopano.io/
                                          https://kb.kopano.io/

                                          Support overview:
                                          https://kopano.com/support/

                                          1 Reply Last reply Reply Quote 0
                                          • jengelh
                                            jengelh Banned last edited by

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

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post