Icecast video streaming with OBS

In this post I’ll outline configuration steps for streaming video from an Icecast server with OBS as the source.

The intention is to be able to self-host a video stream that could be used for a variety of purposes, such as “watch/view together” use.

The configuration below has been tested to keep each connected viewer closely synced to the same point in the stream. The difference in sync between viewers stays roughly between 0-2 seconds in testing. If this isn’t of importance to you, then you may benefit from increasing the Icecast queue-size and burst-size.

A self-signed SSL certificate will be generated in this example, with SSL/TLS used for the OBS > Icecast connection, and for the Viewer > Icecast connections. The Icecast server will be streaming publically unless you setup firewalling to do otherwise, or if you password protect the viewer connections (by putting Icecast behind a password protected NGINX proxy or similar).

Setup Icecast

This was tested on a Vultr 1 vCPU / 2GB RAM server running Fedora 33 x64.

  1. Stop firewalld, as the cloud provider’s firewall around the instance will suffice for testing. Just make sure port 22 & 443 are accessible.
    systemctl stop firewalld
    
  2. Install Icecast
    dnf install -y icecast
    
  3. Generate a self-signed SSL certificate.
    openssl req -x509 -nodes -days 365 -subj '/CN=icecastserver/O=icecastserver/C=SG' -newkey rsa:4096 -keyout /usr/share/icecast/ssl.crt -out /usr/share/icecast/ssl.crt
    
    chmod 644 /usr/share/icecast/ssl.crt
    
  4. Make sure the following items are set within the Icecast configuration, within their respective sections.
    vim /etc/icecast.xml
    
    <limits>
        <queue-size>2046000</queue-size>
        <burst-size>1024000</burst-size>
    </limits>
    
    <listen-socket>
            <port>443</port>
        <bind-address>icecast-server-ip-address-goes-here</bind-address>
        <ssl>1</ssl>
    </listen-socket>
    
    <paths>
            <ssl-certificate>/usr/share/icecast/ssl.crt</ssl-certificate>
    </paths>
    
    <authentication>
            <source-password>password-goes-here</source-password>
            <relay-password>password-goes-here</relay-password>
            <admin-user>admin</admin-user>
            <admin-password>password-goes-here</admin-password>
    </authentication>
    
  5. Start Icecast
    icecast -b -c /etc/icecast.xml
    

Setup OBS

This was tested with OBS v27.0.1 running on Fedora 33 Linux – If you’re intending to use OBS from Windows 10 or OSX, then you’ll likely need to check the Troubleshooting section with respect to potential SSL/TLS connection issues.

  1. Setup OBS to stream to Icecast as follows:
    File > Settings > Output
    Output Mode          = Advanced
    
    Select the "Recording" tab
        Type                       = Custom Output (FFmpeg)
        File path or URL           = icecast://source:<source-password>@<ip-address>:<port>/<mountpoint>.ts
        Container Format           = mpegts
        Muxer Settings             = content_type=video/m2ts tls=1
        Video Bitrate              = 6000 Kbps
        Keyframe interval (frames) = 250
        Show all codecs            = Ticked
        Video Encoder              = libx264
        Audio Bitrate              = 192 Kbps
        Audio Encoder              = libopus
    
  2. Click Start Recording to start streaming from OBS to the Icecast server.

Connect to the Icecast stream

  1. Open the .ts URL of the Icecast server using your media player of choice (MPV, PotPlayer, VLC etc)

    mpv https://<ip-address>/<mountpoint>.ts
    

Troubleshooting

The media player disconnects mid stream or struggles to start the stream, and you don’t think it’s a bandwidth issue.
  • Try increasing the Icecast queue-size and burst-size, or reducing the Video Bitrate within OBS streaming to Icecast.
As soon as you click Start Recording in OBS, it errors out with Error number -10054 occurred; ffmpeg_data_init failed.
  • In testing, this occured when trying to connect to Icecast over SSL/TLS, but only on Windows 10 and not under Linux (Fedora 34). OBS 27.0.1 was used on both systems. This appears to be due to differences between FFmpeg versions that may end up being used by OBS across these two tested OS setups. A way to fix this on Windows 10 is to use a newer version of FFmpeg with OBS that supports the Icecast tls option to Establish a TLS (HTTPS) connection to Icecast , or to disable SSL/TLS on the Icecast listen-socket that you’re connecting to. Both approaches are outlined as below, depending on which you’d prefer to use.
Updating FFmpeg on Windows 10 OBS in order to connect to Icecast over SSL/TLS.
  1. Download a shared release of a recent version of FFmpeg. v4.4 was tested as working. You can grab it from here or here.
  2. Extract the contents of the bin directory into the OBS bin directory, and overwrite any existing files. The path is typically C:\Program Files\obs-studio\bin\
  3. Try connecting OBS to the Icecast server once again now, it should work.
Alternatively: Disable SSL/TLS

You only need to apply this to the icecast listen-socket you connect OBS to, you can still have another listen-socket setup in the Icecast configuration for any viewers to connect with SSL/TLS if desired. You can use the adjusted config below to connect OBS to Icecast on port 8000 without SSL/TLS.

# Set <ssl> to 0 under the <listen-socket> section, and set the <port> to 8000

        <listen-socket>
            <port>8000</port>
            <bind-address>icecast-server-ip-address-goes-here</bind-address>
            <ssl>0</ssl>
        </listen-socket>

# Set `tls=0` inside the OBS `Muxer Settings` (OBS will likely still connect if it's set to `tls=1`, as long as SSL isn't enabled on the Icecast `listen-socket` you're connecting to):

        File > Settings > Output

        Output Mode                 = Advanced
        Select the "Recording" tab
        Muxer Settings              = content_type=video/m2ts tls=0
  • Open the .ts URL of the Icecast server using your media player of choice (MPV, PotPlayer, VLC etc)
    mpv http://<ip-address>:8000/<mountpoint>.ts
    
How can I get this to use a browser friendly video container so I can stream within a web browser?
  • You can try using webm for the Container Format inside OBS, with libvpx or libvpx-vp9 as the Video Encoder. I encountered performance issues on the encoding end when testing this, but your milage may vary.

Adding QT Colour Schemes to Kate when running Gnome (or how to get the dark mode back!)

If you’ve been running QT based applications under Gnome for long enough, it’s likely that you’ll eventually encounter issues with inconsistent theming and colour schemes when it comes to having QT and/or KDE based applications try to match or inherit parts of the Gnome / GTK theme you’re running. Note that this scenario is not specific to Gnome, and you can experience this issue and also fix it the same way on other desktop environments.

A particular example I’ve encountered occurred when moving from Fedora 32 to 33. The text editor “Kate” no longer uses a dark colour scheme if you’ve got the supplied “Adwaita-dark” applied to Gnome.

Notice how the outer GUI is white. Previously in Fedora 32 it would match the dark GUI colours used by the “Adwaita-dark” Gnome theme, however this no longer occurs in Fedora 32. Note that the inner editor’s “Colour Theme” works fine. It’s using “Solarized Dark”.


There are no issues setting a “Colour Theme” under Kate’s “Editor Component” settings – however this only applied to the inner editor. What we want is a theme we can choose under “Settings > Colour Scheme”. The only option you’ll see is “Default” – at least with Kate under Fedora 33.


We can fix this by installing Kvantum. We actually don’t even need to perform any configuration either! Simply installing it will be enough.

sudo dnf install kvantum
Whoa. We now have different “Colour Schemes” to choose from!


Now that Kvantum is installed, if you check “Settings > Colour Scheme” inside Kate, you’ll see a bunch of different options. “KvGnomeDark” will get you the same dark theme that gets inherited when running Kate under Fedora 32 using the “Adwaita-dark” Gnome theme. There are other nice options too, like “KvAdaptaDark”.

It’s worth mentioning that Kvantum has more to it than just what has been demonstrated here. Kvantum can be used to “hook” into QT applications and set specific theme/scheme options across QT applications. I’d recommend checking out these YouTube guides below.

Fixing Windows 10 bootloader with bcdboot

In this tutorial I will outline one way to fix an issue with the Windows 10 bootloader if you’ve run into an issue. This isn’t the only possible option, however I found this worked for me after performing a restore of the main NTFS OS partition but not any of the boot or system partitions at this same time. This may also help if your Windows 10 installation isn’t detected on boot after performing a disk clone, or if you’ve installed a fresh copy of Windows 10 to fix a boot issue, and then tried to restore the NTFS OS partition over the top of that fresh install, but then the OS doesn’t boot. You may simply see a Windows boot screen with an error, or a black screen with a message along the lines of “No operating system installed”.


You’ll need access to some form of Windows 10 installation media, such as a USB drive or DVD. You can download the media creation tool from Microsoft here – https://www.microsoft.com/en-au/software-download/windows10

Boot your PC into the Windows 10 installation media.

At the first screen which asks for region information, click next. You’ll then see a “Repair your computer” option at the very bottom left. Click on this.

From here you should be able to go “Troubleshoot”, then “Advanced Options”, and finally “Command Prompt”.


At the command prompt, type –

diskpart
list volume


You should see a list of volumes (partitions) that are detected. We want to locate the volume that is used for your bootloader. Typically this is going to be the one without a drive letter already assigned, and it’ll usually be a small partition under 1GB in size. It’ll also use a FAT32 filesystem.

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     X                NTFS   Simple      1863 GB  Healthy
  Volume 1     C                NTFS   Partition    162 GB  Healthy    
  Volume 2                      FAT32  Partition    600 MB  Healthy    
  Volume 3     R                NTFS   Partition    111 GB  Healthy
  Volume 4     S                NTFS   Partition    111 GB  Healthy
  Volume 5     Z                NTFS   Partition    931 GB  Healthy
  Volume 6     V                NTFS   Partition   2794 GB  Healthy
  Volume 7     D                FAT32  Removable     28 GB  Healthy


We need to select that volume and assign a drive letter to it –

select volume 2
assign letter B
list volume


When you list the volumes again, you should now see that the volume “2” has been assigned letter “B” –

 Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     X                NTFS   Simple      1863 GB  Healthy
  Volume 1     C                NTFS   Partition    162 GB  Healthy    
  Volume 2     B                FAT32  Partition    600 MB  Healthy    
  Volume 3     R                NTFS   Partition    111 GB  Healthy
  Volume 4     S                NTFS   Partition    111 GB  Healthy
  Volume 5     Z                NTFS   Partition    931 GB  Healthy
  Volume 6     V                NTFS   Partition   2794 GB  Healthy
  Volume 7     D                FAT32  Removable     28 GB  Healthy


Exit diskpart at this point and you’ll be dropped back into the normal command prompt –

exit


Here we’ll run the “bcdboot” command. In this case, you want to first define the volume that you know has your Windows installation on it – your main NTFS OS partition. Typically you can figure this out based on the size if you know what that would be, if not… you’ll need to search around for more pointers as it’s beyond what I’ll be explaining here.


The command will be set to first define the volume where your Windows installation is, and then the drive letter we just assigned for the drive with the bootloader. So for instance we have “volume 1 – C” as our Windows install, and “volume 2 – B” as the boot volume.

bcdboot C:\Windows -s B:


This should (hopefully!) succeed, and then on reboot you’ll be able to boot into Windows. If you happen to see multiple “Windows” installs to choose from, where one is the one we’ve just fixed, but the other leads nowhere – you can run “msconfig” inside windows and go to the “Boot” tab, and then delete that second option from the boot menu.


Toshiba Canvio Slim 2TB Portable 2.5″ USB 3.0 HDD – HDTD320AS3EA / MQ04UBD200 Benchmark

Below are some basic benchmarks of the Toshiba Canvio Slim 2TB Portable 2.5″ USB 3.0 HDD – HDTD320AS3EA – Which in this instance has a Toshiba MQ04UBD200 drive inside. Please note these are purely just for my own interest and for anyone else interested – these tests are not performed for proper review purposes or under strict testing environment settings, so they may not be perfectly accurate, however they should represent ballpark figures of what to expect (unless I’ve made a mistake in my benchmark process!). At the time of writing, these can be sourced for ~$99 AUD and come with a 3 year warranty.

CrystalDiskInfo SMART details for the drive inside – a 2TB Toshiba MQ04UBD200.
CrystalDiskMark benchmark results (formatted)
Read speed benchmark from HD Tune (formatted)
Minimum – 32.7 MB/s
Maximum – 136.7 MB/s
Average – 104.6 MB/s
Access Time – 18.5 ms
Burst Rate – 157.1 MB/s
Write speed benchmark from HD Tune (unformatted)
Minimum – 0.1 MB/s
Maximum – 124.6 MB/s
Average – 41.9 MB/s
Access Time – 8.20 ms
Burst Rate – 123.7 MB/s

Simplecom CHN411 USB C to 3 Port USB 3.0 Hub with Gigabit Ethernet ( RTL8153 ) Benchmark

This is the silver version. It is also available in black.

Below are some basic iperf benchmarks of the Simplecom CHN411 USB C to 3 Port USB 3.0 Hub with Gigabit Ethernet adapter. Only the ethernet port was benchmarked as I don’t have any very high speed USB devices to test the USB 3.0 hub ports with. The adapter is confirmed to be using a Realtek RTL8153 chip for the ethernet port. This is a very common chip and you’ll likely see the same one in use across many similar looking adapters with different branding on the outside. The testing was performed using a direct connection between the adapter and a bare metal machine that uses an Intel 82574L Gigabit NIC.

iperf3 TCP test

[  5] local 192.168.1.2 port 45814 connected to 192.168.1.2 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   113 MBytes   952 Mbits/sec    0    288 KBytes       
[  5]   1.00-2.00   sec   112 MBytes   941 Mbits/sec    0    288 KBytes       
[  5]   2.00-3.00   sec   112 MBytes   941 Mbits/sec    0    303 KBytes       
[  5]   3.00-4.00   sec   112 MBytes   943 Mbits/sec    0    318 KBytes       
[  5]   4.00-5.00   sec   112 MBytes   939 Mbits/sec    0    318 KBytes       
[  5]   5.00-6.00   sec   113 MBytes   944 Mbits/sec    0    318 KBytes       
[  5]   6.00-7.00   sec   112 MBytes   941 Mbits/sec    0    318 KBytes       
[  5]   7.00-8.00   sec   112 MBytes   941 Mbits/sec    0    318 KBytes       
[  5]   8.00-9.00   sec   112 MBytes   940 Mbits/sec    0    318 KBytes       
[  5]   9.00-10.00  sec   113 MBytes   945 Mbits/sec    0    318 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.10 GBytes   943 Mbits/sec    0             sender
[  5]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec                  receiver
iperf UDP test

------------------------------------------------------------
Client connecting to 192.168.1.1, UDP port 5001
Sending 1470 byte datagrams, IPG target: 11.76 us (kalman adjust)
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.2 port 46526 connected with 192.168.1.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.11 GBytes   957 Mbits/sec
[  3] Sent 813889 datagrams
[  3] Server Report:
[  3]  0.0- 0.0 sec  1.11 GBytes  -nan bits/sec   0.037 ms    0/813889 (0%)

The results are on par with my expectations and I haven’t had any compatibility issues with the device across different operating systems.

Asus Zenbook UX431F display won’t work on Fedora 30 Linux without “NOMODESET”

Upon installing Fedora 30 to an Asus Zenbook UX431F, I encountered an issue where there is no display output unless “nomodeset” is inside the GRUB config. This limits the display resolution to 800×600 for the Zenbook’s screen which isn’t ideal. External monitors will work just fine though.

The first issue of note is that the Fedora live ISO will not output anything to the monitor when going through the normal installation process. At the boot prompt when using the live ISO you’ll need to go to Troubleshooting and Install Fedora in basic graphics mode.


Once Fedora has installed run through the following steps –

  • Download 1920×1080.bin from here or here.
  • Move that file to /lib/firmware/edid/
  • Edit /etc/default/grub and remove nomodeset then add the following line to the bottom – GRUB_CMDLINE_LINUX_DEFAULT="drm.edid_firmware=eDP-1:edid/1920x1080.bin"
  • Run sudo grub2-mkconfig -o /boot/grub2/grub.cfg
  • Reboot


Fedora should boot up and display at the proper 1920×1080 60hz resolution. After doing this there is an unfortunate issue wherein the onboard audio seems to stop working. I’m unsure as to why this is but if you use an external audio device such as a USB DAC or USB headset – audio will work fine through that. The onboard audio does work prior to this fix, however the system volume slider simply returns the volume as off or at maximum rather than incrementing properly. Edit – After a running a recent yum update I’m no longer having any issues with the onboard audio.

This issue appears to be present across most Linux distributions on some Asus Zenbook devices as tested by other users. It might also be a wider issue for devices using the Intel HD 620 integrated GPU. For further information on the actual bug and the original source of this fix, please refer to the following links –

https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1821533
https://ubuntuforums.org/showthread.php?t=2420705

AzuraCast – Simple, open-source self-hosted web radio

For many years now I have hosted internet radio and internet radio events using a very simple stack of just IceCast + EZStream, tied in with a few very simple scripts and cron jobs. This has always worked incredibly reliably and kept these setups very minimal with less parts in the chain to potentially have an issue or drive up resource usage. The negative of this has always been a lack of flexibility. In the past I had looked into software such as Centova Cast, however this comes at a cost and isn’t an open-source solution – which is what I will generally opt for where possible.

Introducing AzuraCast! I have been experimenting with AzuraCast for the last few months and it certainly shows a lot of promise. Rather than repeating specifics about it myself – here is a copy-paste directly from their GitHub.

AzuraCast is a self-hosted, all-in-one web radio management suite. Using its easy installer and powerful but intuitive web interface, you can start up a fully working web radio station in a few quick minutes.

Features

For Radio Stations

  • Rich Media Management: Upload songs, edit metadata, preview songs and organize music into folders from your browser.
  • Playlists: Add music to standard-rotation playlists (in sequential or shuffled playback order) or schedule a playlist to play at a scheduled time, or once per x songs/minutes/etc.
  • Live DJs: Set up individual DJ/streamer accounts and see who’s currently streaming from your station’s profile page.
  • Web DJ: Broadcast live directly from your browser, with no extra software needed, with AzuraCast’s built-in Web DJ tool.
  • Public Pages: AzuraCast includes embeddable public pages that you can integrate into your existing web page or use as the basis for your own customized player.
  • Listener Requests: Let your listeners request specific songs from your playlists, both via an API and a simple public-facing listener page.
  • Remote Relays: Broadcast your radio signal (including live DJs) to any remote server running Icecast or SHOUTcast.
  • Web Hooks: Integrate your station with Slack, Discord, TuneIn, Twitter and more by setting up web hooks that connect to third-party services.
  • Detailed Analytics and Reports: Keep track of every aspect of your station’s listeners over time. View reports of each song’s impact on your listener count. You can also generate a report that’s compatible with SoundExchange for US web radio royalties.

For Server Administrators

  • Role-based User Management: Assign global and per-station permissions to a role, then add users to those roles to control access.
  • Custom Branding: Modify every aspect of both the internal and public-facing AzuraCast pages by supplying your own custom CSS and JavaScript.
  • Authenticated RESTful API: Individual users in the system can create API keys which have the same permissions they have in the system. The AzuraCast API is a powerful and well-documented tool for interacting with installations.
  • Web Log Viewing: Quickly diagnose problems affecting any part of the AzuraCast system through the system-wide web log viewer.
  • Automatic Radio Proxies: Many users can’t connect directly to radio station ports (i.e. 8000) by default, so AzuraCast includes an automatic nginx proxy that lets listeners connect via the http (80) and https (443) ports. These proxies are also compatible with services like CloudFlare.

AzuraCast is still currently in beta, however the developers seem very active on the project and updates are regular. This is definitely a long awaited alternative to the commercial/paid software solutions for managing internet radio. I’m very excited to watch how this project develops. For more information, check out their website over at – https://www.azuracast.com/

Verbatim 16GB Store N Go USB 3.0 Flash Drive VBPLAT16GB Benchmark

Below are some basic benchmarks of the Verbatim 16GB Store N Go Platinum USB 3.0 Flash Drive – Model – VBPLAT16GB. “Platinum” in this case refers to the colour only. There are also “Gold” versions of these same flash drives with the same specifications. Please note these are purely just for my own interest and for anyone else interested – these tests are not performed for proper review purposes or under strict testing environment settings, so they may not be perfectly accurate, however they should represent ballpark figures of what to expect (unless I’ve made a mistake in my benchmark process!)


CrystalDiskMark benchmark results (formatted)
Read speed benchmark from HD Tune (unformatted)
Minimum – 109.2 MB/s
Maximum – 138.6 MB/s
Average – 126.4 MB/s
Access Time – 0.566 ms
Burst Rate – 74.8 MB/s
Write speed benchmark from HD Tune (unformatted)
Minimum – 6.1 MB/s
Maximum – 25.7 MB/s
Average – 18.6 MB/s
Access Time – 613.9 ms
Burst Rate – 65.7 MB/s

SanDisk 16GB Ultra USB 3.0 Flash Drive SDCZ4816GB Benchmark

Below are some basic benchmarks of the SanDisk 16GB Ultra USB 3.0 Flash Drive – Model – SDCZ4816GB. Please note these are purely just for my own interest and for anyone else interested – these tests are not performed for proper review purposes or under strict testing environment settings, so they may not be perfectly accurate, however they should represent ballpark figures of what to expect (unless I’ve made a mistake in my benchmark process!)


CrystalDiskMark benchmark results (formatted)

Read speed benchmark from HD Tune (unformatted)
Minimum – 94.5 MB/s
Maximum – 117.7 MB/s
Average – 104.5 MB/s
Access Time – 0.683 ms
Burst Rate – 75 MB/s

Write speed benchmark from HD Tune (unformatted)
Minimum – 4.7 MB/s
Maximum – 16.2 MB/s
Average – 11.9 MB/s
Access Time – 4.40 ms
Burst Rate – 75.7 MB/s

Installing Rocket.Chat on Ubuntu Xenial 16.04 via Snap

This is a simple tutorial to get Rocket.Chat running on a Ubuntu Xenial 16.04 server (You’ll likely be perfectly fine to run through the same process on a different Ubuntu version such as 18.04 if you’d prefer) In this case we’re installing this on a fresh server and we’ll be installing Rocket.Chat as a Snap and using Caddy as a reverse proxy. Caddy will also deal with issuing SSL certificates via Let’s Encrypt. With this you’ll be able to get Rocket.Chat up and running within ~10 minutes, from there you can go on and make further server configuration changes for security and so on, as well as configure Rocket.Chat in more depth – which won’t be covered within the scope of this tutorial.


Let’s first start with some updates.

apt-get update
apt-get upgrade


Basic UFW setup

Let’s setup a basic firewall using UFW. First install UFW if it’s not installed –

apt-get install ufw


Setup the default access rules –

ufw default deny incoming
ufw default allow outgoing


Setup the firewall rules that we’ll want –

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp


Enable the firewall –

ufw enable


You can check the status of ufw with –

ufw status


If you add or remove rules you should reload ufw with –

ufw reload


If you need to disable ufw you can do so with –

ufw disable


Install Fail2Ban

apt-get install fail2ban


Install Rocket.Chat as a Snap

Install Snap if it’s not already installed –

apt-get install snapd


Install Rocket.Chat –

snap install rocketchat-server


At this point the Rocket.Chat service will have automatically started, you can check if it’s running with –

service snap.rocketchat-server.rocketchat-server status


Configure Caddy and SSL

Initial configuration-

snap set rocketchat-server caddy-url=https://<your-domain-name>
snap set rocketchat-server caddy=enable
snap set rocketchat-server https=enable
rocketchat-server.initcaddy


Assuming you didn’t have any errors, restart Rocket.Chat and Caddy –

systemctl restart snap.rocketchat-server.rocketchat-server.service
systemctl restart snap.rocketchat-server.rocketchat-caddy.service


You can check Caddy’s logs with the following command

journalctl -r | grep caddy | less


Redirect HTTP to HTTPS

Redirecting HTTP to HTTPS is handled in the Caddy configuration by ommitting the http or https prefix. For instance you should have something like this inside /var/snap/rocketchat-server/current/Caddyfile –

your-domain-name.com {
  proxy / localhost:3000 {
    websocket
    transparent
  }
}


Restart Caddy once again after saving your changes –

systemctl restart snap.rocketchat-server.rocketchat-caddy


Onto Rocket.Chat itself!

At this point you’ll have a working Rocket.Chat installation running. You can browse to https://yourserver.com and you should be presented with the Setup Wizard screen to create the first user whom will by the Admin by default.

Once logged in, you may get a pop-up stating something along the lines of – The setting Site URL is configured to http://localhost and you are accessing from https://yourserver.com - Do you want to change to https://yourserver.com ? – You’ll want to click YES.

At this stage you’ll want to setup Rocket.Chat itself, so please refer to their documentation here – https://rocket.chat/docs


~Extra~

You can install a Discord style dark theme using this here! https://github.com/0x0049/Rocket.Chat.Dark