Good Nighttime,
I'm using the current docker-jitsi-meet image behind an Apache 2.6 reverse proxy that does the SSL handling. The LDAP Daemon is listening only the the local host.
My docker-compose is the following:
networks:
meet.jitsi: {}
services:
jicofo:
depends_on:
- prosody
environment:
ENABLE_AUTH: '1'
JIBRI_BREWERY_MUC: jibribrewery
JIBRI_PENDING_TIMEOUT: '90'
JICOFO_AUTH_PASSWORD: passw0rd
JICOFO_AUTH_USER: focus
JICOFO_COMPONENT_SECRET: s3cr37
JICOFO_RESERVATION_REST_BASE_URL: null
JIGASI_BREWERY_MUC: jigasibrewery
JIGASI_SIP_URI: null
JVB_BREWERY_MUC: jvbbrewery
TZ: Europe/Berlin
XMPP_AUTH_DOMAIN: auth.meet.jitsi
XMPP_DOMAIN: xmpp.jitsi
XMPP_INTERNAL_MUC_DOMAIN: internal-muc.meet.jitsi
XMPP_SERVER: xmpp.jitsi
image: jitsi/jicofo
networks:
meet.jitsi: null
volumes:
- /etc/jitsi/jicofo:/config:rw
jvb:
depends_on:
- prosody
environment:
DOCKER_HOST_ADDRESS: 136.243.230.177
JVB_AUTH_PASSWORD: passw0rd
JVB_AUTH_USER: jvb
JVB_BREWERY_MUC: jvbbrewery
JVB_ENABLE_APIS: null
JVB_PORT: '10000'
JVB_STUN_SERVERS: meet-jit-si-turnrelay.jitsi.net:443
JVB_TCP_HARVESTER_DISABLED: "true"
JVB_TCP_PORT: '4443'
TZ: Europe/Berlin
XMPP_AUTH_DOMAIN: auth.meet.jitsi
XMPP_INTERNAL_MUC_DOMAIN: internal-muc.meet.jitsi
XMPP_SERVER: xmpp.jitsi
image: jitsi/jvb
networks:
meet.jitsi: null
ports:
- 10000:10000/udp
- 4443:4443/tcp
volumes:
- /etc/jitsi/jvb:/config:rw
prosody:
environment:
AUTH_TYPE: ldap
ENABLE_AUTH: '1'
ENABLE_GUESTS: '0'
GLOBAL_CONFIG: null
GLOBAL_MODULES: null
JIBRI_RECORDER_PASSWORD: passw0rd
JIBRI_RECORDER_USER: recorder
JIBRI_XMPP_PASSWORD: passw0rd
JIBRI_XMPP_USER: jibri
JICOFO_AUTH_PASSWORD: passw0rd
JICOFO_AUTH_USER: focus
JICOFO_COMPONENT_SECRET: s3cr37
JIGASI_XMPP_PASSWORD: passw0rd
JIGASI_XMPP_USER: jigasi
JVB_AUTH_PASSWORD: passw0rd
JVB_AUTH_USER: jvb
JWT_ACCEPTED_AUDIENCES: null
JWT_ACCEPTED_ISSUERS: null
JWT_ALLOW_EMPTY: null
JWT_APP_ID: null
JWT_APP_SECRET: null
JWT_ASAP_KEYSERVER: null
JWT_AUTH_TYPE: null
JWT_TOKEN_AUTH_MODULE: null
LDAP_AUTH_METHOD: bind
LDAP_BASE: DC=network,DC=internal
LDAP_BINDDN: cn=binddn,dc=network,dc=internal
LDAP_BINDPW: [bindpw goes here]
LDAP_FILTER: (objectclass=posixAccount)
LDAP_START_TLS: null
LDAP_TLS_CACERT_DIR: null
LDAP_TLS_CACERT_FILE: null
LDAP_TLS_CHECK_PEER: null
LDAP_TLS_CIPHERS: null
LDAP_URL: ldap://localhost/
LDAP_USE_TLS: '0'
LDAP_VERSION: null
LOG_LEVEL: null
TZ: Europe/Berlin
XMPP_AUTH_DOMAIN: auth.meet.jitsi
XMPP_DOMAIN: xmpp.jitsi
XMPP_GUEST_DOMAIN: guest.meet.jitsi
XMPP_INTERNAL_MUC_DOMAIN: internal-muc.meet.jitsi
XMPP_INTERNAL_MUC_MODULES: ''
XMPP_MODULES: ''
XMPP_MUC_DOMAIN: muc.meet.jitsi
XMPP_MUC_MODULES: ''
XMPP_RECORDER_DOMAIN: recorder.meet.jitsi
expose:
- '5222'
- '5347'
- '5280'
image: jitsi/prosody
networks:
meet.jitsi:
aliases:
- xmpp.jitsi
volumes:
- /etc/jitsi/prosody:/config:rw
web:
environment:
DISABLE_HTTPS: '1'
ENABLE_AUTH: '1'
ENABLE_GUESTS: '0'
ENABLE_HTTP_REDIRECT: '0'
ENABLE_LETSENCRYPT: '0'
ENABLE_RECORDING: null
ENABLE_TRANSCRIPTIONS: null
ETHERPAD_URL_BASE: null
JIBRI_BREWERY_MUC: jibribrewery
JIBRI_PENDING_TIMEOUT: '90'
JIBRI_RECORDER_PASSWORD: passw0rd
JIBRI_RECORDER_USER: recorder
JIBRI_XMPP_PASSWORD: passw0rd
JIBRI_XMPP_USER: jibri
JICOFO_AUTH_USER: focus
LETSENCRYPT_DOMAIN: null
LETSENCRYPT_EMAIL: null
PUBLIC_URL: https://jitsi
TZ: Europe/Berlin
XMPP_AUTH_DOMAIN: auth.meet.jitsi
XMPP_BOSH_URL_BASE: http://xmpp.meet.jitsi:5280
XMPP_DOMAIN: xmpp.jitsi
XMPP_GUEST_DOMAIN: guest.meet.jitsi
XMPP_MUC_DOMAIN: muc.meet.jitsi
XMPP_RECORDER_DOMAIN: recorder.meet.jitsi
image: jitsi/web
networks:
meet.jitsi:
aliases:
- xmpp.jitsi
ports:
- 5080:80/tcp
- 5443:443/tcp
volumes:
- /etc/jitsi/web:/config:rw
- /etc/jitsi/web/letsencrypt:/etc/letsencrypt:rw
- /etc/jitsi/transcripts:/usr/share/jitsi-meet/transcripts:rw
version: '3.0'
My Apache 2.6 reverse proxy is configured the following
<VirtualHost jitsi:443>
[SSL-Settings]
ProxyVia On
ProxyRequests Off
ProxyPreserveHost on
<Location />
ProxyPass http://localhost:5080/
ProxyPassReverse http://localhost:5080/
</Location>
<Proxy *>
Options FollowSymLinks MultiViews
Require all granted
</Proxy>
</VirtualHost>
The issue is the saslauth-configuration generated by docker compose
{{ if eq (.Env.AUTH_TYPE | default "internal") "ldap" }}
ldap_servers: {{ .Env.LDAP_URL }}
ldap_search_base: {{ .Env.LDAP_BASE }}
{{ if .Env.LDAP_BINDDN | default "" }}
ldap_bind_dn: {{ .Env.LDAP_BINDDN }}
ldap_bind_pw: {{ .Env.LDAP_BINDPW }}
{{ end }}
ldap_filter: {{ .Env.LDAP_FILTER | default "uid=%u" }}
ldap_version: {{ .Env.LDAP_VERSION | default "3" }}
ldap_auth_method: {{ .Env.LDAP_AUTH_METHOD | default "bind" }}
{{ if .Env.LDAP_USE_TLS | default "0" | toBool }}
ldap_tls_key: /config/certs/{{ .Env.XMPP_DOMAIN }}.key
ldap_tls_cert: /config/certs/{{ .Env.XMPP_DOMAIN }}.crt
{{ if .Env.LDAP_TLS_CHECK_PEER | default "0" | toBool }}
ldap_tls_check_peer: yes
ldap_tls_cacert_file: {{ .Env.LDAP_TLS_CACERT_FILE | default "/etc/ssl/certs/ca-certificates.crt" }}
ldap_tls_cacert_dir: {{ .Env.LDAP_TLS_CACERT_DIR | default "/etc/ssl/certs" }}
{{ end }}
{{ if .Env.LDAP_TLS_CIPHERS }}
ldap_tls_ciphers: {{ .Env.LDAP_TLS_CIPHERS }}
{{ end }}
{{ end }}
{{ end }}
{{ if .Env.LDAP_START_TLS | default "0" | toBool }}
ldap_start_tls: yes
{{ end }}
The issue is the saslauth-configuration generated by docker compose
What exactly?
@saghul It looks like the saslauth config is completely invalid and is filled with the jinja template used for rendering the config out of the env.
I temporarily worked around this by writing the config by hand and mounting it to the container
The problem is here probably:
Its only running the previous condition, on this one the file already exists, so its not being processed by the tpl command ?
Edit... just noticed its two diferent paths.
Did you already have a default /etc/saslauthd.conf file? Sorry I have no LDAP setup I can test with here. if it ddoes have a default file, then we'd need to remove it at container build time.
I was able to fix it by stopping all of the services, removing the containers, cleaning out the config volumes, and starting it again. Because the config is persisted in the volumes it seems like you have to delete their contents if you want the environment varables to properly update the config.
I'm not sure if that is intentional or if that should be a bug report.
That is intentional and documented.
There is no saslauth running on the host itself, thus the /etc/saslauthd.conf is not existing.
The one within the container is - as written - not generated properly.
Not ssure I follow. What are its contents? Is it not being templated correctly?
This seems to be the problem I am suffering too. The saslauthd.conf does not get rendered and is output as a jinja template.
{{ if eq (.Env.AUTH_TYPE | default "internal") "ldap" }}
ldap_servers: {{ .Env.LDAP_URL }}
ldap_search_base: {{ .Env.LDAP_BASE }}
{{ if .Env.LDAP_BINDDN | default "" }}
ldap_bind_dn: {{ .Env.LDAP_BINDDN }}
ldap_bind_pw: {{ .Env.LDAP_BINDPW }}
{{ end }}
ldap_filter: {{ .Env.LDAP_FILTER | default "uid=%u" }}
ldap_version: {{ .Env.LDAP_VERSION | default "3" }}
ldap_auth_method: {{ .Env.LDAP_AUTH_METHOD | default "bind" }}
{{ if .Env.LDAP_USE_TLS | default "0" | toBool }}
ldap_tls_key: /config/certs/{{ .Env.XMPP_DOMAIN }}.key
ldap_tls_cert: /config/certs/{{ .Env.XMPP_DOMAIN }}.crt
{{ if .Env.LDAP_TLS_CHECK_PEER | default "0" | toBool }}
ldap_tls_check_peer: yes
ldap_tls_cacert_file: {{ .Env.LDAP_TLS_CACERT_FILE | default "/etc/ssl/certs/ca-certificates.crt" }}
ldap_tls_cacert_dir: {{ .Env.LDAP_TLS_CACERT_DIR | default "/etc/ssl/certs" }}
{{ end }}
{{ if .Env.LDAP_TLS_CIPHERS }}
ldap_tls_ciphers: {{ .Env.LDAP_TLS_CIPHERS }}
{{ end }}
{{ end }}
{{ end }}
{{ if .Env.LDAP_START_TLS | default "0" | toBool }}
ldap_start_tls: yes
{{ end }}
That is not the file that is being used. Check on /etc on the container itself.
That is not the file that is being used. Check on /etc on the container itself.
Interesting. So the mounted file in /config should be jinja? I have edited it and have successfully authenticated. I'll revert it and retry.
Thanks for the response.
I must have entered something incorrectly as I tore it all down and it rebuilt and worked.
Thank you.
Most helpful comment
That is not the file that is being used. Check on /etc on the container itself.