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

    Unable to access HTTP/HTTPS endpoints with various services

    General Discussion
    3
    7
    476
    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.
    • tiredofit
      tiredofit last edited by

      Good day, I am currently evaluating the usage of Kopano and so far I am very impressed! I’ve managed to get a working installation based on sockets however I am unable to have success with HTTP/HTTPS endpoints. While Kopano Gateway and Webapp work, I cannot get dagent, spamd, spooler, search to connect to the server with the following errors. Can you give some insight as to what I am doing wrong?

      I have tried this repeatedly with nightly builds going back for the past 3 weeks. Debian Buster.

      server.cfg

      server_listen = *:236
      

      dagent.cfg - NOT WORKING

      server_socket = http://localhost:236
      

      dagent.log

      2020-05-28T06:24:39.138240: [kopano-dagent|T8885] [error  ] HrLogon server "http://localhost:236" user "SYSTEM": logon failed
      2020-05-28T06:24:39.138289: [kopano-dagent|T8885] [error  ] Access denied or connection failed for user "SYSTEM" using socket "http://localhost:236": logon failed (80040111)
      2020-05-28T06:24:39.138385: [kopano-dagent|T8885] [debug  ] Current uid:998 username:kopano
      2020-05-28T06:24:39.138403: [kopano-dagent|T8885] [error  ] void* HandlerLMTP(void*): HrGetSession failed: logon failed (80040111)
      2020-05-28T06:24:39.138410: [kopano-dagent|T8885] [debug  ] < 421 internal error: GetSession failed
      2020-05-28T06:24:39.138455: [kopano-dagent|T8885] [info   ] LMTP thread exiting
      

      gateway.cfg - WORKING (this is interesting as I am not prefixing the protocol)

      server_socket = localhost:236
      

      spamd.cfg - NOT WORKING

      server_socket = http://localhost:236
      

      spamd.log

      2020-05-28 06:27:19,266 - spamd - INFO - starting spamd
      2020-05-28 06:27:21,540 - spamd - INFO - stopping spamd
      2020-05-28 06:27:22,541 - spamd - ERROR - Traceback (most recent call last):
        File "/usr/lib/python3/dist-packages/kopano/server.py", line 320, in __init__
          flags=flags)
        File "/usr/lib/python3/dist-packages/MAPI/Util/__init__.py", line 72, in OpenECSession
          admin.ConfigureMsgService(uid, 0, 0, profprops)
        File "/usr/lib/python3/dist-packages/MAPICore.py", line 1661, in ConfigureMsgService
          return _MAPICore.IMsgServiceAdmin_ConfigureMsgService(self, lpUID, ulUIParam, ulFlags, cValues)
      MAPI.Struct.MAPIErrorLogonFailed: MAPI error 80040111 (MAPI_E_LOGON_FAILED)
      
      During handling of the above exception, another exception occurred:
      
      Traceback (most recent call last):
        File "/usr/lib/python3/dist-packages/kopano/service.py", line 182, in start
          config=self.config, service=self)
        File "/usr/lib/python3/dist-packages/kopano/service.py", line 101, in _daemonize
          _daemon_helper(func, service, log)
        File "/usr/lib/python3/dist-packages/kopano/service.py", line 46, in _daemon_helper
          func()
        File "/usr/lib/python3/dist-packages/kopano_spamd/__init__.py", line 34, in main
          server = self.server
        File "/usr/lib/python3/dist-packages/kopano/service.py", line 167, in server
          _skip_check=True)
        File "/usr/lib/python3/dist-packages/kopano/server.py", line 332, in __init__
          password incorrect')
      kopano.errors.LogonError: Could not logon to server: username or password incorrect
      
      

      spooler.cfg WORKING

      server_socket = http://localhost:236
      

      spooler.log

      2020-05-28T06:29:07.500891: [=======] Starting kopano-spooler version 10.0.5 (pid 9641 uid 0)
      2020-05-28T06:29:07.500978: [kopano-spooler|T9641] [info   ] Coredump status left at system default.
      2020-05-28T06:29:07.501349: [kopano-spooler|T9641] [debug  ] Reexecing /usr/sbin/kopano-spooler
      2020-05-28T06:29:07.512611: [=======] Starting kopano-spooler version 10.0.5 (pid 9641 uid 998)
      2020-05-28T06:29:07.512698: [kopano-spooler|T9641] [info   ] Coredump status left at system default.
      2020-05-28T06:29:07.520198: [ 9641] [info   ] Starting statscollector
      2020-05-28T06:29:07.520246: [ 9641] [debug  ] Using SMTP server: mta-selfdesign-dev-app, port 25
      2020-05-28T06:29:07.522698: [ 9641] [error  ] HrLogon server "http://localhost:236" user "SYSTEM": logon failed
      2020-05-28T06:29:07.522745: [ 9641] [error  ] Unable to open admin session: logon failed (80040111)
      2020-05-28T06:29:07.522758: [ 9641] [warning] Server connection lost. Reconnecting in 3 seconds...
      

      Webapp WORKING
      webapp/config.php

      define("DEFAULT_SERVER", "http://localhost:236");
      
      fbartels 1 Reply Last reply Reply Quote 0
      • fbartels
        fbartels Kopano @tiredofit last edited by

        Hi @tiredofit,

        some components (like spooler, dagent, search) need to perform a login on their own with kopano-server to get access. When not using a unix socket, this is done through the means of https and ssl client certificates.

        This is explained in the manual at https://documentation.kopano.io/kopanocore_administrator_manual/special_kc_configurations.html#running-kc-components-beyond-localhost.

        Since this lead to some confusion a few weeks ago, there are components that do not log in on their own, but rather a user logs in through them (like kopano webapp for example). For these you do not need/should not use ssl client certificates as this would mean that the connection is implicitly elevated to an admin session without further password checks (because the connection is already authenticated through the ssl cert).

        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
        • tiredofit
          tiredofit last edited by

          Thanks @fbartels - This aligns with what I was thinking with being allowed to login via webapp and gateway due to the passing of my own credentials. I will figure this out. I have incorrectly assumed that I could use http without the need for a certificate on the same box so will focus my efforts on https!

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

            90% there - All with the exception of Search now connect over a secure channel.
            I noted that someone else raised an issue to this which seems to be exactly the way I am doing things.

            Just to confirm that I am on track here:

            search.cfg

            server_socket = https://server:237
            sslkey_file = /certs/core/search.pem
            server_bind_name = https://0.0.0.0:238
            ssl_private_key_file = /certs/core/search-bind.pem
            ssl_certificate_file = /certs/core/public/search-bind-public.pem
            

            server.cfg

            search_enabled = yes
            search_socket = https://search:238
            

            I believe after learning about the HTTPS client certificates I have the sslkey_file component correct, but am not entirely sure I have the bind certs correct. I’ve made the assumption that they are x509 certificates and that the server should be able to read the “bind” certificate in the public folder, yet get presented with a SYSTEM logon error.

            All of my certificates are generated the same way, and after following the instruction in the manpage to generate a keypair for the bind pair I still get presented with a system logon error which not much else to go on.

            Any tips?

            1 Reply Last reply Reply Quote 0
            • fbartels
              fbartels Kopano last edited by

              Hi @tiredofit,

              without trying it out myself, but it reads like you simply switched the meaning of some of the config options.

              sslkey_file (and additionally sslkey_pass) are used to authenticate the connection towards kopano-server.

              ssl_private_key_file and ssl_certificate_file are used for searches own https endpoint.

              I would argue that within your own network you do not really need to make search listen on a https endpoint, as this one is only used for transport encryption.

              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
              • tiredofit
                tiredofit last edited by

                Agreed, not entirely necessary except when on a local system yet Multiserver, I can see how this would be required.

                Just to wrap my head further around this, the Search options (not related to connecting to Kopano Server) are similar to how gateway works - They are services meant to be exposed to the internet and use a standard cert/key pair and don’t rely on client certificates. If so I’ll keep plugging away and focus on the Kopano Server connection which is the one that is causing me the SYSTEM user logon grief.

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

                  Login as SYSTEM(admin) is only possible with AF_LOCAL socket or https transport.

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