The ungleich Matrix infrastructure » History » Revision 17

Revision 16 (Jin-Guk Kwon, 11/19/2020 08:35 AM) → Revision 17/22 (Jin-Guk Kwon, 12/10/2020 10:16 AM)

h1. The ungleich Matrix infrastructure 


 *%{color:red}This document concerns the infrastructure side of our MaaS offer and is intended for ungleich staff. See [[Ungleich Matrix-as-a-Service (MaaS)]] page for end-user/customer documentation. Common operations can be found on: [[]].%* 

 h2. Status 

 This document is *A DRAFT*. This service is not in production. Ask @fnux for details. 

 h2. Environment 

 Our Matrix deployments make use of the "Synapse (reference) Matrix homeserver": and "Riot web client": We use Debian buster as base Operating system, leveraging the "matrix-synapse package from the buster-backports repository": The riot client (= static files) is directly fetched from "upstream releases on github": 

 The matrix deployments run on ipv6only VMs, HTTP(S) traffic - including federation - being proxy by the [[How to use the IPv4-to-IPv6-Proxy|ungleich v4-to-v6 proxy]]. Federation is delegated using a @/.well-known/@ URI as described in [[Ungleich Matrix-as-a-Service (MaaS)|the customer FAQ]]. 


 h2. Tooling 

 The whole MaaS setup is defined in the *manifest/matrix-as-a-service* of *dot-cdist* file, which wraps the *__ungleich_matrix* type. This type leverages: 

 * *__matrix_synapse* 
 * *__matrix_riot* 
 * *__ungleich_nginx_static_type* 
 * *__postgres_role* and *__postgres_database* from upstream cdist. 

 The "matterbridge": application service can be deployed with the *__matterbridge* type. 

 *Matrix Federation Tester:* 

 h2. Synapse Admin UI 

 * Available on: 
 * Leverages 
 * Static deployment hence hosted on staticweb. 

 * Allows manual admin management of users and rooms. 
 * Use direct address of homeserver for login: @ 

 h2. Monitoring 

 Autodiscovered from consul in monitoring LAN. 

 h2. Ungleich Deployments 

 We maintain our own deployments alongside the customer MaaS, both for our own usage and for testing. 


 Staging instance used to tests the deployment pipeline and Matrix updates. 


 Production instance for ungleich. Some rooms are bridged to the "": mattermost instance. The bridge makes use of the local matrix user (i.e. not from LDAP) and @matterbridge@ mattermost user (linked to matterbridge AT ungleich ch). 

 h2. Customer Deployments 

 That's too sensitive to be public: "this way": ! 
 h2. Shared TURN server 

 Coturn is running at See @matrix-as-a-service@ manifest in dot-cdist for details. 


 h2. create mass users on matrix host 

 - info.txt 

 FirstName LastName Email user_id1 pw1 
 FirstName LastName Email user_id2 pw2 
 FirstName LastName Email user_id3 pw3 

 - creating user shall script 

 while read A B C D E 
   pw=$E register_new_matrix_user -u $A -p $B --no-admin -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008 
   name=$A" "$B 
   data='{"password":"'${pw}'", "displayname": "'${name}'", "threepids": [ { "medium": "email", "address": "'${ad}'" }], "admin": false, "deactivated": false, "avatar_url": null }' 
   h='Authorization: Bearer <AccessToken>' 
   curl -v -X PUT -H "$h" -d "$data" http://localhost:8008/_synapse/admin/v2/users/$ 
   sleep 2 echo "$A" "$B" 
 done < info.txt 


 h2. invite mass users on matrix host 

 - info.txt 

 user_id1 pw1 
 user_id2 pw2 
 user_id3 pw3 

 - get user token 

 --> user : admin room user 

 curl -XPOST -d '{"type":"m.login.password", "user":"[user_id]", "password":"[user_password]"}' "http://localhost:8008/_matrix/client/r0/login" 

 - inviting user script 


   cat <<EOF 

 while read A B 
    curl -XPOST -d "$(generate_post_data)" "http://localhost:8008/_matrix/client/r0/rooms/[room_id]/invite?access_token=[user_token]" 
 done < info.txt