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

    Meet Components Not reading .cfg files

    Kopano Meet & WebMeetings
    3
    7
    2013
    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 noticing that the dependencies to run Kopano Meet don’t seem to be taking command line arguments nor reading the .cfg files properly.

      Grapi (10.2.0+0.200fd8f-0+27.1)
      grapi.cfg

      root@c2978d8e82e6:/etc/kopano# cat /etc/kopano/grapi.cfg 
      num_workers = 8
      insecure = no
      socket_path = /tmp/grapi/kopano-grapi
      pid_file = /tmp/grapi/grapi.pid
      server_socket = file:///var/run/kopano/server.sock
      persistency_path = /tmp/data/grapi
      enable_experimental_endpoints = no
      log_level = debug
      

      Running Manually:

      root@c2978d8e82e6:/etc/kopano# kopano-grapi serve &
      [1] 29810
      root@c2978d8e82e6:/etc/kopano# mkdir: cannot create directory '': No such file or directory
      2020-05-29 05:22:26,045 master    [29810] INFO     starting kopano-mfr
      

      Checking to see existence of sockets

      root@c2978d8e82e6:/tmp/grapi/kopano-grapi# ls -l
      total 0
      
      ps -ef --width 400
      root       29810   18553  0 05:22 pts/1    00:00:00 grapi master --socket-path=/var/run/kopano-grapi --workers=8 --pid-file=/var/run/kopano-grapi/grapi.pid --process-name=grapi
      

      When adding arguments on the command line it gets even stranger:

      root@c2978d8e82e6:/tmp/grapi/kopano-grapi# kopano-grapi serve --socket-path /tmp/grapi/kopano-grapi --pid-file /tmp/grapi/grapi.pid --workers 2 --process-name test &
      
      root@c2978d8e82e6:/tmp/grapi/kopano-grapi# mkdir: cannot create directory '': No such file or directory
      2020-05-29 05:27:52,187 master    [30092] INFO     starting kopano-mfr
      
      root@c2978d8e82e6:/tmp/grapi/kopano-grapi# ps -ef --width 400
      
      root       30092   18553  3 05:27 pts/1    00:00:00 grapi master --socket-path /tmp/grapi/kopano-grapi --pid-file /tmp/grapi/grapi.pid --workers 2 --process-name test --socket-path=/var/run/kopano-grapi --workers=8 --pid-file=/var/run/kopano-grapi/grapi.pid --process-name=grapi
      

      KWMServerd (1.1.0-0+333.2) is not reading the configuration file either.

      root@c2978d8e82e6:/etc/kopano# cat kwmserverd.cfg  |grep oidc
      oidc_issuer_identifier=https://foo.bar
      

      KWMServerd is parsing listen arguments, however not the ISS provider.

      root@c2978d8e82e6:/tmp/grapi/kopano-grapi# kopano-kwmserverd serve --listen 127.0.0.1:8776 --iss https://oidc.local &
      [1] 30374
      root@c2978d8e82e6:/tmp/grapi/kopano-grapi# INFO[0000] serve start                                  
      INFO[0000] using external TURN service: https://turnauth.kopano.com/turnserverauth/ 
      INFO[0000] serve started                                
      WARN[0010] failed to initialize OIDC provider            error="Timeout (:0x105)" iss="https://localhost"
      WARN[0010] admin: using random admin tokens singing key - API endpoint admin disabled 
      INFO[0010] rtm: API endpoint enabled                    
      INFO[0010] starting http listener                        listenAddr="127.0.0.1:8776"
      INFO[0010] ready to handle requests                     
      

      Kapid (0.14.0-0+337.2) similar with not parsing ISS argument

      kapid.cfg

      root@c2978d8e82e6:/etc/kopano# cat kapid.cfg |grep "oidc"
      oidc_issuer_identifier=https://foo.bar
      
      root@c2978d8e82e6:/tmp/grapi/kopano-grapi# kopano-kapid serve --listen 127.0.1.1:8038 --iss https://oidc.local 
      INFO[0000] serve start                                  
      INFO[0000] loading plugins from /usr/lib/kopano/kapid-plugins 
      INFO[0000] plugin loaded: /usr/lib/kopano/kapid-plugins/grapi.so  build=reproducible plugin=grapi version=0.14.0
      INFO[0000] plugin loaded: /usr/lib/kopano/kapid-plugins/kvs.so  build=reproducible plugin=kvs version=0.14.0
      INFO[0000] plugin loaded: /usr/lib/kopano/kapid-plugins/pubs.so  build=reproducible plugin=pubs version=0.14.0
      INFO[0000] plugin registered                             plugin=grapi
      INFO[0000] plugin registered                             plugin=kvs
      INFO[0000] plugin registered                             plugin=pubs
      INFO[0000] serve started                                
      INFO[0000] grapi: access requirements set up             required_scopes="[profile email kopano/gc]"
      INFO[0000] kvs: access requirements set up               required_scopes="[kopano/kvs]"
      WARN[0000] pubs: using random secret key                
      INFO[0000] pubs: access requirements set up              required_scopes="[kopano/pubs]"
      WARN[0005] grapi: waiting for proxy rest*.sock files to appear  error="no proxy rest*.sock files found in socket-path"
      WARN[0005] grapi: waiting for proxy notify*.sock files to appear  error="no proxy notify*.sock files found in socket-path"
      WARN[0010] failed to initialize OIDC provider            error="Timeout (:0x105)" iss="https://localhost"
      INFO[0010] starting http listener                        listenAddr="127.0.1.1:8038"
      INFO[0010] ready to handle requests    
      
      longsleep 1 Reply Last reply Reply Quote 0
      • longsleep
        longsleep Kopano @tiredofit last edited by longsleep

        @tiredofit

        How do you start the services? They are supposed to start via systemd and it’s systemd which loads the configuration files and not the services itself.

        If you start the services manually for whatever reason without systemd, use the command line arguments or in certain cases env variables.

        See for example https://github.com/Kopano-dev/kwmserver/blob/master/scripts/kopano-kwmserverd.service#L17 and https://github.com/Kopano-dev/kwmserver/blob/master/scripts/kopano-kwmserverd.binscript for the script taking them - it’s similar for the other services.

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

          Thanks @longsleep - I didn’t realize they were actually shell scripts setting variables. I am working on this in Docker and figured they would read the .cfg files similar to other Kopano services. I can easily work this into my use case. Will report back on my successes.

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

            Hi @tiredofit,

            @tiredofit said in Meet Components Not reading .cfg files:

            I am working on this in Docker

            ah. interesting. I’ve been working on https://github.com/zokradonh/kopano-docker (which has your self-service password container as an optional part) for quite a while and was lucky enough to have a few external contributions already. I would be very much interesting in working together on something.

            I have sent you a direct message.

            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

              Sure thing. I have a solution now which is parsing the files similar to how systemd parses with the “EnvironmentFile” argument and I have a working Konnect, KAPI, KWM, GRAPI solution. I’ve been going at this for 4 weeks strong now during all my spare time to build a solution that’s entirely conrolled via environment variables, but also allow for a setup with sane defaults with only a few settings to change, namely server names. I’m quite a ways away from getting to where I want this which is being able to operate off of one image and control all functions spending on a MODE env var, which you saw in another thread (http/https endpoints), but I’ll get that one figured out too.

              Happy to collaborate and share, my images are fairly non standard and primarily built for my team who works under me (I am CIO and do this for fun), but more than happy to release into the wild so that others may benefit.

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

                @tiredofit said in Meet Components Not reading .cfg files:

                I have a solution now which is parsing the files similar to how systemd parses with the “EnvironmentFile” argument

                I have solved it by removing spaces around the equal sign and then exporting each non commented line in the cfg. You can have a look at https://github.com/zokradonh/kopano-docker/blob/1120a8e08b8ceb84fd096d79ef851fb86981f39c/core/start-service.sh#L186-L188

                The overall goal of the above project was to provide containers that each run one component of Kopano while being flexible enough to adapt to different environments. It sounds a bit like you are aiming at running with as few containers as possible.

                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

                  OK, very similar to how I did mine as well. I’m calling a function which does it so I can use it some of my other images.
                  While I am going for a single container solution, I also have the functionality to split out each service into their own discrete container, yet using the same image, which I believe you are doing as well for many services. While that functionality hasn’t entirely been tested on the meet services, it is certainly working on KC components using shared sockets. One difference is I’m not using Kweb but pure nginx. I hope to have some of the bits that are bothering me sorted out in the next few days and I’ll put it up for review.

                  parse_config() {
                      if [ -f ${1} ] ; then
                          print_debug "Parsing Config ${1}"
                          while IFS="" read -r line || [ -n "$line" ]
                              do
                              if [[ "${line}" == *" = "* ]] ; then
                                  name=`echo $line | awk '{print $1}'`
                                  value=`echo $line | awk '{print $3}'`
                                  export $name=$value
                              fi
                          done < ${1}
                      else
                          print_error "Tried to parse config ${1} but it doesn't exist!"
                      fi
                  }
                  
                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post