| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| computing:synapse [2022/11/23 07:21] – 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** |
| |
| ------------------------------------------- | ------------------------------------------- |
| <email:> | <email:> |
| <smtp_host: haacksnetworking.org> | <smtp_host: haacksnetworking.org> |
| <smpt_port: 587> | <smpt_port: 25> |
| <notif_from: "admin@gnulinux.club"> | <notif_from: "admin@gnulinux.club"> |
| <require_transport_security: true> | <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 with domains that are allowed to send through it explicitly white listed. 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.: | 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' | curl https://download.jitsi.org/jitsi-key.gpg.key | sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg' |
| systemctl restart matrix-synapse | 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''. Note: I can't seem to get jitsi to work as intended withing the matrix rooms, but it does work on it's own; I suspect it is glitching with the video lab. You are now done! However, make sure to snapshot your VPS if in a cloud, and/or if you are using kvm and a virtual machine on your own hardware, consider creating a backup script for the vms as follows: | 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]] |
| |
| [[https://repo.haacksnetworking.org/oemb1905/haackingclub/-/blob/master/scripts/sane-vm-backup.sh|appropriate backup scripts]] | Lastly, I also have a hot-spare in case my co-located hardware fails. Swing on by: |
| |
| 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/23 00:21// | --- //[[jonathan@haacksnetworking.org|oemb1905]] 2022/12/11 14:48// |
