Meet Components Not reading .cfg files



  • 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    
    

  • Kopano

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



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


  • Kopano

    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.



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


  • Kopano

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



  • 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
    }
    

Log in to reply