Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
computing:synapse [2022/11/23 07:21] – oemb1905 | computing:synapse [2022/11/24 03:54] – oemb1905 |
---|
<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> |
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: |
| |
[[https://repo.haacksnetworking.org/oemb1905/haackingclub/-/blob/master/scripts/sane-vm-backup.sh|appropriate backup scripts]] | - 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: |
| |
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/11/23 20:49// |