[__jitsi_meet] bug for parameter --secured-domains

pedro commented

2022-01-27 02:57:09 +00:00

problems with the block type on __jitsi_meet https://code.ungleich.ch/ungleich-public/cdist-contrib/src/branch/master/type/__jitsi_meet/manifest#L174-L185 :

it uses replace state that does not exist (I checked the source code's type), so I don't know why the type is not failing explicitly, it's failing implicitly, if we enable this, is going to do it in the wrong way [1], that would break jicofo during restart, and making the jitsi instance unavailable
there is no way to apply a regex condition about where to apply the block

I suggest/propose using the __file type with a template and a conditional part would be the ex-block

extra note, old created cdist jitsi instances still work because they use /etc/jitsi/jicofo/sip-communicator.properties method as documented here https://jitsi.github.io/handbook/docs/devops-guide/secure-domain

[1]

root@meet:~# cat /etc/jitsi/jicofo/jicofo.conf 
# Jicofo HOCON configuration. See /usr/share/jicofo/jicofo.jar/reference.conf for
#available options, syntax, and default values.
jicofo {
  xmpp: {
    client: {
      client-proxy: focus.meet.xes.cat
    }
    trusted-domains: [ "recorder.meet.example.com" ]
  }
}
// begin cdist: jicofo_secured_domains
  authentication: {
    enabled: true
    type: XMPP
    login-url: meet.example.com
  }
// end   cdist: jicofo_secured_domains

problems with the block type on *__jitsi_meet* https://code.ungleich.ch/ungleich-public/cdist-contrib/src/branch/master/type/__jitsi_meet/manifest#L174-L185 : - it uses replace state that does not exist (I checked the source code's type), so I don't know why the type is not failing explicitly, it's failing implicitly, if we enable this, is going to do it in the wrong way [1], that would break jicofo during restart, and making the jitsi instance unavailable - there is no way to apply a regex condition about where to apply the block I suggest/propose using the *__file* type with a template and a conditional part would be the ex-block extra note, old created cdist jitsi instances still work because they use `/etc/jitsi/jicofo/sip-communicator.properties` method as documented here https://jitsi.github.io/handbook/docs/devops-guide/secure-domain [1] ``` root@meet:~# cat /etc/jitsi/jicofo/jicofo.conf # Jicofo HOCON configuration. See /usr/share/jicofo/jicofo.jar/reference.conf for #available options, syntax, and default values. jicofo { xmpp: { client: { client-proxy: focus.meet.xes.cat } trusted-domains: [ "recorder.meet.example.com" ] } } // begin cdist: jicofo_secured_domains authentication: { enabled: true type: XMPP login-url: meet.example.com } // end cdist: jicofo_secured_domains ```

evilham referenced this issue from a commit

2022-03-10 20:22:04 +00:00

[__jitsi_meet] Fix bug with secured domains

evilham closed this issue

2022-03-10 20:22:04 +00:00

pedro commented

2022-03-14 23:19:27 +00:00

Author

thanks @evilham, now the issue is partially solved. It would work when the block already exist, but it's going to fail when the block is not there (when configuration change from publicly accessible instance to secured domain instance, that includes a new jitsi instance). The code block would be added at the end causing a syntax error in the config, see [0] from my first message

I did not do more tests, and I don't know if I misunderstood, but I reviewed a little bit the __block type, and I don't see guarantees for the situation I am saying. It's good for a non-dependent positioned code block in a generic config file, but here, the code block must be placed on a specific position: inside jicofo json object

thanks @evilham, now the issue is partially solved. It would work when the block already exist, but it's going to fail when the block is not there (when configuration change from publicly accessible instance to secured domain instance, that includes a new jitsi instance). The code block would be added at the end causing a syntax error in the config, see [0] from my first message I did not do more tests, and I don't know if I misunderstood, but I reviewed a little bit the `__block` type, and I don't see guarantees for the situation I am saying. It's good for a non-dependent positioned code block in a generic config file, but here, the code block must be placed on a specific position: inside jicofo json object

pedro reopened this issue

2022-03-14 23:19:34 +00:00

evilham referenced this issue from a commit

2022-04-10 17:51:32 +00:00

[__jitsi_meet] Unconfuse jitsi-version and secured domains

evilham closed this issue

2022-04-10 17:51:32 +00:00

[__jitsi_meet] bug for parameter --secured-domains #15