| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| computing:synapse [2022/11/21 18:40] – oemb1905 | computing:synapse [2022/12/11 21:48] – oemb1905 |
|---|
| * **Jonathan Haack** | * **Jonathan Haack** |
| * **Haack's Networking** | * **Haack's Networking** |
| * **webmaster@haacksnetworking.org** | * **webmaster@haacksnetworking.org** |
| |
| ------------------------------------------- | ------------------------------------------- |
| register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008 | register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008 |
| | |
| Record the password you chose in a safe location, and then uncomment the user registration on ''/etc/matrix-synapse/homeserver.yaml'' again and once again restart the service ''systemctl restart matrix-synapse''. This is required because you cannot manually create users while the ''enable_registration: true'' parameter is active. Likely, you will now want to also create a non-admin user for yourself, and the webgui is very convenient for this so just visit element.gnulinux.club and then register. Once you log in, make sure that you can access federated instances, spaces, and rooms. So long as everything is working, let's carry on with setting up jitsi: | Record the password you chose in a safe location, and then uncomment the user registration on ''/etc/matrix-synapse/homeserver.yaml'' again and once again restart the service ''systemctl restart matrix-synapse''. This is required because you cannot manually create users while the ''enable_registration: true'' parameter is active. Likely, you will now want to also create a non-admin user for yourself, and the webgui is very convenient for this so just visit element.gnulinux.club and then register. Once you log in, make sure that you can access federated instances, spaces, and rooms. The last thing we need to do is add the ability for the server to send emails so users can recover accounts when needed via email. To do that, first make sure you have a working [[https://wiki.haacksnetworking.org/doku.php?id=computing:exim4|https://wiki.haacksnetworking.org/doku.php?id=computing:exim4]]email server. Please note that an incoming (IMAP) server is not needed, only outgoing (smtp/MTA). Once that is setup, add the following lines to your ''/etc/matrix-synapse/homeserver.yaml'' configuration: |
| |
| | sudo nano /etc/matrix-synapse/homeserver.yaml |
| | <public_baseurl: "https://matrix.gnulinux.club"> |
| | <email:> |
| | <smtp_host: haacksnetworking.org> |
| | <smpt_port: 25> |
| | <notif_from: "admin@gnulinux.club"> |
| | <require_transport_security: true> |
| | |
| | Again, note that there is no need to set up an incoming email server nor tolerate spam on the server you are sending to. In my case, my smtp server / MTA is a relay/MTA (only) with domains that are allowed to send through it explicitly white listed. Now that email is up, let's tweak the upload settings so that people can upload images that are larger than a megabyte and have reasonable purge directives: |
| | |
| | sudo nano /etc/matrix-synapse/homeserver.yaml |
| | <max_upload_size: 1000M> |
| | <dynamic_thumbnails: true> |
| | <media_retention:> |
| | <local_media_lifetime: 90d> |
| | <remote_media_lifetime: 14d> |
| | |
| | Also, make sure to add the following line of code within each nginx http server block: |
| | |
| | <client_max_body_size 1000M;> |
| | |
| | Alright, so now it's time to carry on with setting up jitsi. Again, as with element and matrix, always check the [[https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-quickstart/|official documentation]] for the latest releases/gpg keys, etc.: |
| | |
| | curl https://download.jitsi.org/jitsi-key.gpg.key | sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg' |
| | echo 'deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/' | sudo tee /etc/apt/sources.list.d/jitsi-stable.list > /dev/null |
| | sudo apt update |
| | sudo apt install jitsi-meet |
| | <enter domain jitsi.gnulinux.club> |
| | <generate self-signed> |
| | |
| | Once the install finishes, let's create let's encrypt using the official script from Jitsi, which will automatically configure a turn server and create a server block in nginx for us: |
| | |
| | /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh |
| | |
| | We now need to configure Element to use jitsi, which we do as follows: |
| | |
| | nano /var/www/element.gnulinux.club/element/config.json |
| | <"preferredDomain": "jitsi.gnulinux.club"> |
| | systemctl restart matrix-synapse |
| | |
| | You can verify that jitsi is working by ''ps -aux | jitsi'' and then visit jitsi.gnulinux.club (adjusted for your domain) to verify you can create and join a new meeting. Additionally, you can navigate to ''etc/turnserver.conf'' to see the entries jitsi created and likewise verify the server block it created at ''/etc/nginx/sites-enabled/jitsi.gnulinux.club''. You are now done! However, make sure to run regular snapshots on a cron job, and consider some simple shell scripts to monitor nginx, postgres, and fail2ban and if they fail, to restart them and email you. I also have a separate script that dumps the entire database daily with a time stamp. Here are the scripts currently in use: |
| | |
| | - Keep Fail2Ban Running:[[https://repo.haacksnetworking.org/oemb1905/haackingclub/-/blob/master/scripts/fail2ban-restart.sh|fail2ban-restart.sh]] |
| | - Keep Postgres Running: [[https://repo.haacksnetworking.org/oemb1905/haackingclub/-/blob/master/scripts/postgres-restart.sh|postgres-restart.sh]] |
| | - Keep Nginx Running: [[https://repo.haacksnetworking.org/oemb1905/haackingclub/-/blob/master/scripts/nginx-restart.sh|nginx-restart.sh]] |
| | - Nightly DB Dumps: [[https://repo.haacksnetworking.org/oemb1905/haackingclub/-/blob/master/scripts/postgres-dump.sh|postgres-dump.sh]] |
| | |
| | Also, there's no point in setting this up unless you have regular backups! In my case, since this is a VM, I just use the same script as I use for all my other instances. That script powers down the VM, and copies a sparse file, then tarballs it. After restarting the VM, my backup workstation pulls down the tarballs (also sparse) on a set schedule, keeping approximately 90 days of restore points. The backup script I use is found here and, of course, this runs on the host OS (not the Synapse VM instance): |
| | |
| | - VM Backup Script: [[https://repo.haacksnetworking.org/oemb1905/haackingclub/-/blob/master/scripts/sane-vm-backup.sh|sane-vm-backup.sh]] |
| |
| | Lastly, I also have a hot-spare in case my co-located hardware fails. Swing on by: |
| |
| Between these two debugging tools, you should be in good shape to get everything up and running! Okay, that took a lot to document but it's worth it. Also, if you are serving others in a public facing community, make sure you have [[https://repo.haacksnetworking.org/oemb1905/haackingclub/-/blob/master/scripts/sane-vm-backup.sh|appropriate backup scripts]] for this VM. Utilize rsync or similar to ensure you have those backups offsite as well as on site, and also provision a hot-spare in case your self-hosted or co-located hardware fails. | - [[https://element.gnulinux.club|GNU/Linux Club]] |
| |
| --- //[[jonathan@haacksnetworking.org|oemb1905]] 2022/11/20 01:58// | --- //[[jonathan@haacksnetworking.org|oemb1905]] 2022/12/11 14:48// |
