If you’re running a Linux environment within Windows using WSL, monitoring system resources becomes essential. Htop, a powerful command-line utility, allows you to visualize resource usage, including memory, CPU, and more.

Step 1: Install Htop

First, ensure that Htop is installed. Open your Windows terminal and run:

sudo apt-get update
sudo apt-get install htop

Step 2: Launch Htop

Simply type htop in your terminal and hit Enter. You’ll see a real-time overview of system processes.

Step 3: Sort by Memory Usage

By default, Htop sorts processes by CPU usage. To focus on memory, press F6 (or Ctrl + F6). Select MEM% to sort by memory consumption.

Step 4: Identify the Culprit

Scroll through the list. If you notice an application consuming excessive memory, it’s likely the culprit. In my case, it’s ‘Ollama serve’.

Step 5: Investigate Further

Select the process (use arrow keys) and press F1 for help. You’ll find detailed information about the selected process, including its PID, memory usage, and more.

Step 6: Take Action

Depending on your needs, you can:

• Terminate the process by pressing F9.
• Investigate further using other tools or logs.
• Optimize the application to reduce memory usage.

Remember, Htop provides real-time insights, so keep an eye on it periodically to maintain a healthy system.

In summary, Htop is your go-to tool for identifying memory-hungry processes in your WSL environment. Keep your system lean and efficient by monitoring resource usage effectively! 🚀🔍

I hope you enjoyed reading this blog post and learned something new from it. If you did, please consider supporting me and my work by buying me a coffee via buymeacoffee.com. It’s a simple and easy way to show your appreciation and help me keep creating more content like this. Thank you for your time and attention. Have a great day!

As a tech enthusiast and Plex aficionado, I recently embarked on a mission to streamline my media library. My trusty Synology NAS DS 220+ was the backbone of this endeavor, and PowerShell came to the rescue!

Here’s a snippet of the PowerShell script I used to whip my files into shape, adhering to Plex’s best practices for naming and organization:

# Specify the folder path where your files are located
# Example: $folderPath = 'C:\path\to\your\folder'
$folderPath = 'C:\path\to\your\folder'

# Get all files in the folder
$files = Get-ChildItem -Path $folderPath

foreach ($file in $files) {
    $newName = $file.Name
    
    # Remove unwanted wording
    $newName = $newName -replace '-1ndd', ''
    
    # Add a space before and after the dash
    $newName = $newName -replace '-', ' - '
    
    # Replace underscores with spaces
    $newName = $newName -replace '_', ' '

    # Construct the new file path
    $newPath = Join-Path -Path $folderPath -ChildPath $newName

    # Rename the file
    Rename-Item -Path $file.FullName -NewName $newName

    Write-Host "Renamed '$($file.Name)' to '$newName'"
}

# Cheers to a well-organized Plex library! 🎉

Remember, a tidy media library not only pleases the eye but also ensures smoother streaming experiences. Let’s keep our digital lives clutter-free! 📺🎶

Feel free to customize it further to reflect your personal journey and insights. Happy organizing! 🌟

I hope you enjoyed reading this blog post and learned something new from it. If you did, please consider supporting me and my work by buying me a coffee via buymeacoffee.com. It’s a simple and easy way to show your appreciation and help me keep creating more content like this. Thank you for your time and attention. Have a great day!

Windows Subsystem for Linux (WSL) is a feature that allows you to run Linux applications natively on Windows 10 and Windows 11. WSL supports multiple Linux distributions, such as Ubuntu, Debian, Fedora, and more. You can install and manage these distributions using WSL commands in PowerShell or Windows Command Prompt.

In this blog post, I will show you how I used WSL commands to remove a Linux distribution that was having issues and then install a new and updated distribution. This process is useful if you want to switch to a different Linux distribution or upgrade to a newer version.

Removing a Linux Distribution Using WSL Commands

The first step is to remove the Linux distribution that you want to uninstall from WSL. To do this, you need to use the wsl --unregister command, which will delete the distribution and its files from your system. For example, if you want to remove Ubuntu, you can run the following command:

wsl --unregister ubuntu

You can also use the wsl --list command to see all the installed Linux distributions and their names. For example, the output of this command might look something like this:

Windows Subsystem for Linux Distributions:
Ubuntu (Default)
Debian

Installing a Linux Distribution Using WSL Commands

The next step is to install a new Linux distribution using WSL commands. To do this, you need to use the wsl --install command, which will download and install the Linux distribution of your choice from the online store. You can also specify the name of the distribution you want to install. For example, if you want to install Ubuntu 22.04, you can run the following command:

wsl --install Ubuntu-22.04

You can also use the wsl --list --online command to see the list of available Linux distributions that you can install from the online store. For example, the output of this command might look something like this:

Windows Subsystem for Linux Distributions:
Ubuntu-22.04
Ubuntu-20.04
Debian
Fedora
openSUSE

Setting the Default Linux Distribution and Version Using WSL Commands

After installing a new Linux distribution, you might want to set it as the default one that will launch when you run the wsl command. To do this, you need to use the wsl --set-default command, which will set the default Linux distribution for WSL. For example, if you want to set Ubuntu 22.04 as the default distribution, you can run the following command:

wsl --set-default Ubuntu-22.04

You might also want to set the version of WSL that your Linux distribution will run on. WSL has two versions: WSL 1 and WSL 2. WSL 2 is the latest and recommended version, as it offers better performance, compatibility, and features. To set the version of WSL for your Linux distribution, you need to use the wsl --set-version command, which will convert the distribution to the specified version of WSL. For example, if you want to set Ubuntu 22.04 to run on WSL 2, you can run the following command:

wsl --set-version Ubuntu-22.04 2

You can also use the wsl --list --verbose command to see the list of installed Linux distributions and their versions. For example, the output of this command might look something like this:

Windows Subsystem for Linux Distributions:
Ubuntu-22.04 (Default) (Running) Version 2
Debian (Stopped) Version 1

Conclusion

In this blog post, I showed you how I used WSL commands to remove and install a Linux distribution on Windows. This process is simple and convenient, as you can manage your Linux distributions using WSL commands in PowerShell or Windows Command Prompt. You can also switch between different Linux distributions and versions of WSL as you wish.

I hope you found this blog post helpful and learned something new. If you have any questions or feedback, please leave a comment below. Thank you for reading!

Attending the 2023 Indiana Public Sector Cybersecurity Summit was a valuable experience that provided a comprehensive overview of the latest developments and strategies in defending against cyber threats. Hosted by the Indiana Office of Technology, the summit brought together government technology professionals and cybersecurity leaders from across the state to share insights, experiences, and best practices.

Keynote Address - “Keep Your Head Out of the Cyber Sand”

Bryce Austin, CEO of TCE Strategy, delivered a captivating keynote highlighting the power of processes and procedures over relying solely on tools. Drawing inspiration from the USS Missouri battleship, he illustrated the importance of distinguishing between “Black Phones” for internal communication and “Red Phones” for external connections, emphasizing their critical roles. Expressing concern, he stated, “We have a problem with security, and we are not taking it seriously,” urging a shift in mindset. Recommending his book, “Secure Enough?: 20 Questions on Cybersecurity for Business Owners and Executives”. Rigorous response strategies were encouraged, using the analogy of a squirrel versus a porcupine for a robust security posture. Additionally, Austin shed light on the limitations of geo-location as not being fully security-proof. His engaging keynote left attendees with valuable insights and a call to take security seriously in both personal and professional contexts.

AI + ML in Cyber Defense Panel

Moderated by Phil Bertolini (Senior Vice President, Government Technology), the panel on maximizing the role of AI and ML in cyber defense featured insights from Hemant Jain (Chief Information Security Officer, Office of Technology, State of Indiana), Keith Stover (Senior Solutions Architect, SecOps, OpenText Cybersecurity), and Jason Wright (SLED Practice Lead, Mandiant, now part of Google Cloud). The discussion emphasized the need to verify data when utilizing Generative AI (Gen AI) and the importance of embracing AI and ML without fear. The difficulty in identifying bad actors using Gen AI was acknowledged, with an interesting observation on the improved grammar in phishing emails.

Featured Speakers - “Cyber Resources at the Ready: CISA + MS-ISAC Are Here to Help”

Moderated by Phil Bertolini (Senior Vice President, Government Technology), this panel featuring Bridget Bean (Assistant Director for the Integrated Operations Division, Cybersecurity and Infrastructure Security Agency (CISA)) and Heather Doxon (Regional Engagement Manager, Multi-State Information Sharing and Analysis Center (MS-ISAC)) highlighted the underutilization of resources provided by CISA and MS-ISAC in the public sector. The synergy between these two groups, when combined with organizational teams, was emphasized as a powerful approach to enhancing security coverage and staying ahead of emerging threats. The importance of treating cybersecurity as a collaborative effort and regularly exercising incident response plans was a key takeaway.

Cloud Readiness Panel

Moderated by Mike White (Deputy Chief Technology Officer, IN.gov and Payment Processing Programs, Office of Technology, State of Indiana), the session on cloud readiness featured insights from Elaine Kan (Chief Technology Officer, State Personnel Department, State of Indiana), Ryan Parthasarathy (Managing Director, Accenture), and Sean Totten (Chief Security Officer, Information Technology, City of Fishers). The panel stressed collaborative efforts in understanding shared responsibility models, tailoring security to diverse data types, and implementing effective tagging practices. The need for leadership involvement were highlighted, along with the importance of documenting cloud architecture and maintaining stringent security measures. Vendor relationships and upskilling initiatives were emphasized as well.

Featured Speaker - “Navigating Your Cyber Future”

Dan Lohrmann’s (Senior Fellow, Center for Digital Government) presentation focused on navigating the cyber future, emphasizing the value of tabletop discussions and using current events as exercises. He highlighted the growing threat of hacktivism fueled by social media and the potential impact of quantum computing on decryption. Lohrmann stressed the need to embrace emerging technologies like Generative AI, stating, “We got to get to yes.”

Final Thoughts

In conclusion, the 2023 Indiana Public Sector Cybersecurity Summit provided a wealth of knowledge and insights, emphasizing the collaborative nature of cybersecurity efforts and the need for ongoing vigilance and adaptation in the face of evolving threats. The summit served as an invaluable platform for professionals to exchange ideas and strategies, ultimately contributing to a more resilient and secure public sector in Indiana.

In this blog post, I will share with you how I was able to use MariaDB on my Synology NAS DS 220+ and connect it to a docker container that is also Hosted on my Synology NAS. This also assumes you are ready have MariaDB installed and configured on your Synology NAS. For our example I’ll show you how to setup Monica, an open-source personal CRM which helps you organize your social interactions.

Setup database

First, I created a new database by SSH into my Synology NAS and logging into the MariaDB command line interface and running the following code:

CREATE DATABASE IF NOT EXISTS monica_db;

CREATE USER 'monica_user'@'172.17.0.%' IDENTIFIED BY 'PASSWORD';

GRANT ALL ON monica_db.* TO 'monica_user'@'172.17.0.%';

This code creates a new database called monica_db and a new user called monica_user with the password PASSWORD. The user has access to the database from any IP address that starts with 172.17.0, which is the default network for docker containers on Synology NAS.

Setup Docker Container

Next, I went into the Container Manager app in the Synology NAS and downloaded the Monica:latest registry. I create a new folder in my Docker volume where I keep all of the Docker container persistence data. I created a new container, made sure to use Monica:lastest image, made sure to attach my folder to the container in the configuration along with adding the following environment variables:

DB_PORT=3306
DB_DATABASE=monica_db
DB_USERNAME=monica_user
DB_PASSWORD=PASSWORD
DB_HOST=192.168.1.81

These environment variables tell the Monica container how to connect to the MariaDB database that we created earlier. The DB_HOST is the IP address of my Synology NAS on my local network.

Then I clicked finish/build, waited about 15 minutes (at least for me) for the build to complete. You can follow its progress by going into the container and keeping an eye on the ‘log’ section.

Accessing Monica

Finally I open up my web browser to http://192.168.1.81:8080, I set up the user, which is the admin of application, and I was good to go from there. Now you can enjoy your own self-hosted personal CRM.

Conclusion

Congratulations! You have successfully set up a Docker container using MariaDB that is hosted on your Synology NAS. I hope you enjoyed reading this blog post and learned something new from it. If you did, please consider supporting me and my work by buying me a coffee via buymeacoffee.com. It’s a simple and easy way to show your appreciation and help me keep creating more content like this. Thank you for your time and attention. Have a great day!

In this blog post, I will share with you how I am self-hosting Gitea on my Synology Nas DS 220+. Gitea is a lightweight and open source Git service that allows you to create and manage your own repositories, issues, pull requests, and more. Self-hosting means that you run the service on your own hardware, instead of relying on a third-party provider. This gives you more control, privacy, and customization options for your Git projects.

Prerequisites

• Hardware: Synology NAS (mine is DS220+)
• Software: Container (formely Docker), MariaDB 10 packages

Installation Steps

Now lets get into the setup.

Setting up MariaDB

If you want to use MariaDB as the database backend for Gitea, you need to do some configuration steps. Here is a quick guide on how to set up MariaDB on a Synology NAS:

1. Install MariaDB package via Synology Package Center. You can find it under the Database category. Follow the instructions to complete the installation.
2. Create a new database and a user for Gitea via mysql console. You can access the mysql console by logging in to your NAS via SSH and typing mysql -u root -p. Enter the root password that you set during the installation of MariaDB. 2.1 Grant privileges to the user that you created for Gitea. For example, if your database name is gitea_db and your user name is gitea_user, you can use the following commands:

CREATE DATABASE gitea_db;
CREATE USER 'gitea_user'@'localhost' IDENTIFIED BY 'your_password';
GRANT ALL PRIVILEGES ON gitea_db.* TO 'gitea_user'@'localhost';
FLUSH PRIVILEGES;

That’s it! You have successfully set up MariaDB for Gitea on your Synology NAS. You can now proceed to install Gitea and configure it to use the database that you created.

Configuring Docker and Gitea

1. Install MariaDB package via Synology Package Center. You can find it under the Utilities category. Follow the instructions to complete the installation.
2. You will need to create a docker-compose.yml file in a folder of your choice. This file will define the configuration of the Gitea container, such as the ports, volumes, networks, and environment variables. NOTE, create a new volume in File Station Package so all storage is persistent and save this docker-compose.yml file in it. You can use the following template as a reference:

version: "3"

networks:
  gitea:
    external: false

services:
  server:
    image: gitea/gitea:latest
    container_name: gitea
    environment:
      - USER_UID=YOUR-UID
      - USER_GID=YOUR-GID
      - GITEA__database__DB_TYPE=mysql
      - GITEA__database__HOST=THE-IP-OF-YOUR-DATABASE
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=gitea
      - GITEA__database__PASSWD=YOUR-PASSWORD
    restart: always
    networks:
      - gitea
    volumes:
      - /volume1/docker/gitea/gitea:/data
    ports:
      - "3000:3000"
      - "222:22"

1. You will need to open the Container Packege and Create a new project. Project name I gave was ‘gitea’ and the Path was the volume I created in the File Station and where I stored my docker-compose.yml. It should auto detect your docker-compose.yml and then click Next. This will build out your Docker environment for Gitea.
2. Now you can access the Gitea web UI by opening your browser and typing: http://your.synology.ip:3000 You will be greeted by a page that asks you to complete the initial configuration of Gitea. Here you will need to enter some basic information, such as the site title, the admin account details, and the database settings. Make sure that the database settings match the ones that you specified in the docker-compose.yml file.

Accessing Gitea

Once you have completed the initial configuration, you can log in with your admin account and start using Gitea. You can create new repositories, users, organizations, teams, and more. You can also configure various settings for your Gitea instance, such as authentication methods, email notifications, webhooks, etc.

Conclusion

Congratulations! You have successfully set up a self-hosted Gitea service using Docker on your Synology NAS. I hope you enjoyed reading this blog post and learned something new from it. If you did, please consider supporting me and my work by buying me a coffee via buymeacoffee.com. It’s a simple and easy way to show your appreciation and help me keep creating more content like this. Thank you for your time and attention. Have a great day!

In this blog post, I will share how I configured an Amazon Web Services (AWS) static site to use Cloudflare as its proxy. This setup allows me to benefit from Cloudflare’s security and performance features, such as SSL encryption, caching, and firewall.

The first step was to create an Amazon S3 bucket and give it the name of my sub-domain. For example, if my domain name is example.com, I named my bucket blog.example.com. This is important because it allows Cloudflare to recognize the bucket as the origin server for the sub-domain.

The next step was to add a S3 bucket policy to only allow access from Cloudflare. This way, I can prevent anyone from accessing my site directly through the S3 URL, and force them to go through Cloudflare instead. The bucket policy looks like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Allow Cloudflare",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::blog.example.com/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": [
                        "173.245.48.0/20",
                        "103.21.244.0/22",
                        "103.22.200.0/22",
                        "103.31.4.0/22",
                        "141.101.64.0/18",
                        "108.162.192.0/18",
                        "190.93.240.0/20",
                        "188.114.96.0/20",
                        "97.234.240.0/22",
                        "198.41.128.0/17",
                        "162.158.0.0/15",
                        "104.16.0.0/13",
                        "104.24.0.0/14",
                        "172.64.0.0/13",
                        "131.0.72.0/22",
                        "2400:cb00::/32",
                        "2606:4700::/32",
                        "2803:f800::/32",
                        "2405:b500::/32",
                        "2405:8100::/32",
                        "2a06:98c0::/29",
                        "2c0f:f248::/32"
                    ]
                }
            }
        }
    ]
}

The list of IP addresses in the policy corresponds to Cloudflare’s network ranges, which you can find here: https://www.cloudflare.com/ips/

After that, I uploaded my static content to my S3 bucket using the AWS console or a tool like AWS CLI.

The final step was to set up my CNAME record to point my subdomain to my S3 bucket in Cloudflare’s DNS settings.

I also had to add a Page Rule in Cloudflare and set the URL to my subdomain and set SSL to Flexible.

This means that Cloudflare will encrypt the traffic between the visitor and Cloudflare, but not between Cloudflare and the S3 bucket due to by default only HTTP is used when enabling the S3 bucket for static website hosting.

Once that was all fully configured, my static website was up and running with Cloudflare as its proxy.

I hope you enjoyed reading this blog post and learned something new from it. If you did, please consider supporting me and my work by buying me a coffee via buymeacoffee.com. It’s a simple and easy way to show your appreciation and help me keep creating more content like this. Thank you for your time and attention. Have a great day!

Hey, everyone! I’m back with another post about my journey with AWS CloudFormation. This time, I want to share with you how I created a VPC using a YAML template. A VPC is a virtual private cloud that lets you isolate your AWS resources from the public internet. It’s pretty cool and useful, trust me.

So, how did I do it? Well, first of all, I needed to define a parameter for the VPC CIDR, which is the range of IP addresses that the VPC can use. I did this by adding a ‘Parameters’ section in my template and specifying the ‘Type’, ‘Default’ and ‘Description’ of the parameter. Here’s what it looked like:

Parameters:
 VPCCIDR:
  Type: String
  Default: 10.0.0.0/16
  Description: The CIDR block for the VPC

Next, I needed to create the VPC resource itself. I did this by adding a ‘Resources’ section in my template and specifying the ‘Type’, ‘Properties’ and ‘Metadata’ of the resource. The most important thing here was to give the VPC a name tag using the ‘!Sub’ function of the stack name. This way, I could easily identify which VPC belonged to which stack. Here’s what it looked like:

Resources:
 MyVPC:
  Type: AWS::EC2::VPC
  Properties:
   CidrBlock: !Ref VPCCIDR
   EnableDnsSupport: true
   EnableDnsHostnames: true
   Tags:
    - Key: Name
     Value: !Sub ${AWS::StackName}-VPC
  Metadata:
   Comment: Create a VPC

After I finished writing my template, I saved it as a YAML file. Then, I downloaded and installed AWS CLI on my laptop so that I could deploy my template via the command line. I ran the following command to create a stack named ‘MyVPCStack’ in the us-east-2 region:

aws cloudformation deploy --stack-name MyVPCStack --template-file .\my-vpc-template.yaml --region us-east-2

And bingo! My VPC was created in a matter of minutes. I could see it in the AWS console and verify that it had the correct CIDR block and name tag. I was so proud of myself!

But wait, there’s more. I also learned how to delete my stack using the AWS Toolkit for VS Code. This is a handy extension that lets you interact with your AWS resources from within your VS code editor. I simply right clicked on my stack name in the AWS Explorer and selected ‘Delete’. Then, I confirmed that I wanted to delete the stack and all its resources.

And that’s it! My VPC was gone, just like that. No hassle, no waste, no regrets.

Support

I hope you enjoyed reading this blog post and learned something new from it. If you did, please consider supporting me and my work by buying me a coffee via buymeacoffee.com. It’s a simple and easy way to show your appreciation and help me keep creating more content like this. Thank you for your time and attention. Have a great day!

In this blog post, we’ll discuss how to set up a Gitea container on a Synology NAS (DS220+) using Docker. Gitea is a lightweight, self-hosted Git service that allows you to create and manage repositories for storing code snippets. We’ll also cover the process of upgrading the Gitea container to the latest version when a new release is made.

Part 1: Setting Up Gitea on Synology NAS Using Docker

Step 1: Install Docker on Synology NAS

Open the DiskStation Manager (DSM) web interface. Navigate to the Package Center, search for “Docker,” and click “Install.”

Step 2: Set up a Gitea container

Open the Docker app in DSM. Navigate to the “Registry” tab, search for “gitea,” and download the official Gitea image (gitea/gitea).

Step 3: Create and configure the Gitea container

In the “Image” tab, select the Gitea image and click “Launch.” Configure the container settings, including the container name, volume mappings, network ports, and auto-restart.

Step 4: Deploy the container

Review the settings in the “Create Container” window, and click “Apply” to deploy the container.

Step 5: Access the Gitea web interface

Open a web browser and go to http://[NAS_IP]:3000 (replace “[NAS_IP]” with your Synology NAS IP address). Complete the Gitea setup wizard to configure the admin account, database, and other settings.

Part 2: Upgrading Gitea Container to the Latest Version

Step 1: Pull the latest Gitea image

Open the Docker app in DSM. Go to the “Registry” tab, search for “gitea,” and click “Download.” Select the “latest” tag or the desired version tag.

Step 2: Stop and remove the existing Gitea container

Go to the “Container” tab, stop the current Gitea container, and remove it. This won’t delete the mapped volume data.

Step 3: Create a new Gitea container with the updated image

Go to the “Image” tab, select the updated Gitea image, and click “Launch.” Configure the settings as you did for the original container, ensuring you map the same volume and ports, and enable auto-restart.

Step 4: Start the new container

Go to the “Container” tab, select the new Gitea container, and click “Start.”

Conclusion:

By following these steps, you can easily set up and upgrade a Gitea container on your Synology NAS using Docker. This provides a simple and convenient way to store and manage your code snippets. Remember to regularly check for updates and repeat the upgrade process as needed to keep your Gitea instance up-to-date and secure.

I hope you enjoyed reading this blog post and learned something new from it. If you did, please consider supporting me and my work by buying me a coffee via buymeacoffee.com. It’s a simple and easy way to show your appreciation and help me keep creating more content like this. Thank you for your time and attention. Have a great day!

If you’re like me, you love using Bitwarden as your password manager. It’s secure, open source, and easy to use. But did you know that you can also host your own Bitwarden server on your own hardware? That way, you have full control over your data and don’t have to rely on any third-party service.

I’ve been running my own Bitwarden server on a Linode VM with Ubuntu for a while now, and it’s been working great. But recently, I noticed that there was a new version of Bitwarden available with some cool new features. So I decided to upgrade my server and see what’s new.

In this blog post, I’ll show you how I upgraded my Bitwarden self-hosted instance on Linode using the standard deployment option . This option uses Docker Compose to run multiple containers for different services such as web vault, API, database, etc. If you’re using the unified deployment option, which runs everything in a single container with different database options, the process might be different.

Step 1: Backup Your Data

Before doing anything else, make sure you backup your data. You don’t want to lose all your passwords if something goes wrong during the upgrade process. To backup your data, follow these steps:

• Log into your Linode VM via SSH.
• Navigate to the directory where you installed Bitwarden. For me, it’s /opt/bitwarden.
• Run ./bitwarden.sh backups to create a backup of your database and attachments.
• Copy the backup file from ./bwdata/backups to a safe location.

Step 2: Update Your Server

Now that you have a backup of your data, you can proceed with updating your server. To do this, follow these steps:

• Log into your Linode VM via SSH.
• Navigate to the directory where you installed Bitwarden. For me, it’s /opt/bitwarden.
• Run ./bitwarden.sh updateself to update the Bitwarden script itself.
• Run ./bitwarden.sh update to update all the Docker images and containers.
• Wait for the update process to finish.

Step 3: Enjoy Your New Features

That’s it! You’ve successfully upgraded your Bitwarden self-hosted instance on Linode. Now you can enjoy all the new features that come with the latest version of Bitwarden. Some of them are:

• A redesigned web vault with improved usability and accessibility.
• A new Send feature that lets you securely share files and text snippets with anyone.
• A new Emergency Access feature that lets you grant access to your vault in case of an emergency.
• A new Trash feature that lets you restore deleted items from your vault.

You can learn more about these features from the official blog.

I hope this blog post was helpful for anyone who wants to upgrade their Bitwarden self-hosted instance on Linode. Thanks for reading!