How to Resolve Cache Issues with older version when Upgrading Jitsi Infrastructure

Upgrading the Jitsi infrastructure within the same domain can significantly enhance your video conferencing system. However, during such upgrades, users often encounter cache issues from the previous setup. These cache issues can vary depending on the user's browser and can lead to unexpected problems. In this blog post, we will explore a practical solution to address these cache-related challenges. If you're setting up a server for the first time rather than upgrading one, see our Jitsi Meet AWS deployment guide instead.

Our approach involves modifying the build versions of specific files located within the '/usr/share/jitsi-meet' directory on your Jitsi Meet server. By making these changes, you can ensure that users accessing the upgraded infrastructure will receive and load the latest files directly from the server, eliminating any lingering cache problems.

Please note that the files and lines discussed in this blog may vary depending on the versions you are using.

Let's dive into the step-by-step process to achieve this solution effectively.

Step 1: Identifying Cache-Related Issues

Before proceeding with the solution, it's essential to understand the nature of cache-related issues that can arise when upgrading the Jitsi infrastructure. These issues typically manifest when users attempt to access the upgraded system. Outdated files, stored in their browsers' cache, can lead to unexpected behavior and errors.

Step 2: Finding Versions to Replace

To address these cache issues, we must first identify where specific text patterns exist within files in the '/usr/share/jitsi-meet' directory - the location where the Jitsi Meet web files are installed on a standard Debian-package setup. These text patterns represent the build versions and can be found using the grep command.

Use the following code to find build versions in the form of 'v={version}':

grep -rnw '/usr/share/jitsi-meet' -e 'v=[0-9]*'

Some files may have lengthy lines, making it difficult to find build versions from the terminal. If you encounter this problem, you can exclude directories that contain those files. Here is the code that searches through '/usr/share/jitsi-meet/' but excludes the 'libs/' directory:

grep -rnw '/usr/share/jitsi-meet' -e 'v=[0-9]*' --exclude-dir='libs'

In the output, you will see lines similar to the following:

/usr/share/jitsi-meet/index.html:82: "all.css?v=7531" 

/usr/share/jitsi-meet/static/prejoin.html:30: <script src="libs/lib-jitsi-meet.min.js?v=139"></script>

These lines represent the locations of the build versions you need to modify. Keep note of these build numbers (ex:7531,139) and the files with the path

Step 3: Modifying Build Versions of Files

Now that we have identified the files containing the text patterns we want to replace, let's proceed with modifying the build versions of these files to force a cache refresh. This ensures that users accessing the upgraded infrastructure will receive and load the latest files directly from the server, bypassing any cached content.

Here are the commands to make these changes:

sudo sed -i 's/v=139/v=140/g' /usr/share/jitsi-meet/index.html /usr/share/jitsi-meet/static/dialInInfo.html /usr/share/jitsi-meet/static/prejoin.html

sudo sed -i 's/css/all.css?v=7531/css/all.css?v=7532/g' /usr/share/jitsi-meet/index.html

The first sed command replaces instances of 'v=139' with 'v=140' in selected HTML files. The second sed command updates the version number in the 'all.css' file to '7236' to force a cache refresh for CSS styles.

Please note that you have to add all the files you found, for the related build version, in the suitable command. You can add a space to the end followed by a file name with absolute path, as seen in the below sample command.

<sed command> <space> <file_1> <space> <file_2> <space> <file_3>

Step 4: Test the setup

Now, you can test the setup and verify the solution is working!

Conclusion:

By following these steps, you can effectively resolve cache issues that users may encounter when upgrading your Jitsi infrastructure within the same domain. This solution ensures that users access the latest files directly from the server, enhancing their experience and minimizing potential problems associated with outdated cached content. Remember to exercise caution when using sed for file modifications and always maintain proper backups of your files before making any changes. With these techniques, you can streamline the transition to your upgraded Jitsi infrastructure and provide a seamless experience for your users.

Once your upgrade is live, it's a good time to revisit your Jitsi Meet security settings and, if your TLS certificates are due, our guide on updating SSL on a Jitsi Kubernetes deployment.