Why the Old --releasever Method No Longer Works

In my previous guide, I showed how you could upgrade openSUSE Leap releases with:

sudo zypper --releasever=16.0 dup

That used to work reliably in earlier Leap versions. However, with SLE (SUSE Linux Enterprise) 16, SUSE introduced major backend and repository format changes. The new openSUSE Leap 16.0 release merges more closely with SLE infrastructure, which means the repositories and release metadata formats have changed significantly.

If you try to use the --releasever flag now, you’ll likely see repository or GPG key errors during the upgrade. That’s because the old repository layout no longer matches Leap 16’s new structure.

The New Official Method: opensuse-migration-tool

Instead of manually changing repositories, Leap 16 introduces a dedicated migration utility designed to handle all the details for you. The tool automatically adjusts your repositories, resolves new dependencies, and manages system configuration changes.

Step 1: Install the Migration Tool

First, fully update your Leap 15.6 system:

sudo zypper refresh
sudo zypper up

Then install the new migration package:

sudo zypper install opensuse-migration-tool

Step 2: Run the Migration Process

Start the migration utility:

sudo opensuse-migration-tool

The tool will analyze your current system, identify obsolete packages, and suggest repository transitions for Leap 16.0. The system prompts you to confirm before proceeding with the distribution upgrade.

You’ll want to select openSUSE Leap 16.0 with the arrow keys on your keyboard, select OK and hit Enter.

You will probably encounter the following screen about disabling third-party repositories:

This happens because Leap 16.0 changes how repositories are structured. You can simply hit Enter to confirm.

The upgrade process will then start! Wait a few minutes, then reboot into Leap 16.0 once the process finishes.

Step 3: Reboot into Leap 16.0

After the migration completes, simply reboot:

sudo reboot

You’ll now be running openSUSE Leap 16.0 with the updated repository structure.

Troubleshooting Tips

• Do not use zypper dup --releasever=16.0. It may break dependencies.
• If you encounter repository signature errors, remove or rename old .repo files in /etc/zypp/repos.d/ before re-running the migration tool.
• Ensure your disk has sufficient space and that all third-party repositories are disabled before starting the upgrade.

Final Thoughts

The openSUSE team has streamlined the upgrade path to make system migrations more reliable and aligned with SUSE’s enterprise ecosystem. While older zypper --releasever methods are now deprecated, the openSUSE Migration Tool simplifies the process and ensures compatibility with the new Leap 16 architecture.

The post Upgrade openSUSE Leap to 16.0 from 15.6 appeared first on TechOpt.

This comprehensive guide will walk you through everything you need to know, from selecting the right cable and connectors, to crimping, testing, and troubleshooting your custom cables.

Why Make Your Own Ethernet Cable?

There are several advantages to building your own network cables:

• Custom Lengths: No more coiled-up mess or cables that come up just short. Instead, you can make cables the exact length you need.
• Cost Savings: Bulk ethernet cable and connectors are far cheaper per foot than buying pre-made cables.
• Better Quality Control: You choose the cable type, shielding, and connectors, therefore avoiding cheap copper-clad aluminum (CCA) cables.
• Skill Building: This is a useful DIY skill for anyone interested in networking, home labs, or IT work.

Tools and Materials Needed

Here’s what you’ll need to make DIY ethernet cables successfully:

• Ethernet Cable (Cat6, Cat6a, or Cat5e): Prefer solid copper rather than CCA for best performance and compliance with standards. Cat6 bulk cable on Amazon
• RJ45 Connectors: Choose connectors rated for your cable type (Cat6, Cat6a, or Cat5e). Passthrough connectors are easier for beginners. Cat6 RJ45 passthrough connectors
• RJ45 Crimping Tool: Used to secure connectors to the cable. Most crimpers also include a wire cutter and stripper. RJ45 crimp tool
• Cable Tester (Recommended, but optional): Ensures your wiring is correct and detects any faults. Basic cable tester or advanced network tester
• Strain Relief Boots (Recommended, but optional): Add durability to the connector ends. Strain relief boots
• Wire Cutters/Scissors: For trimming cable and internal wires. Wire strippers/cutters

Tip: Avoid “Cat7” or “Cat8” cables sold cheaply online. These are not officially recognized Ethernet standards and often use questionable materials.

Step 1: Measure and Cut Your Cable

Pull the amount of cable you need from the box, then add roughly 30 cm (about 1 foot) of extra length for trimming and flexibility. Cut the cable cleanly using the crimper’s cutting blade or a pair of wire cutters.

Step 2: Strip the Outer Jacket

Use the stripping blade on your crimping tool (or a dedicated wire stripper) to remove 5–10 cm (2–3 inches) of the outer jacket from both ends of the cable. Be careful not to nick the internal wires.

After that, remove the internal string, if present.

At this stage, slide on the strain relief boots if you’re using them—forgetting them is a common mistake. Therefore, it’s best to add them now. You want the larger side facing outward from the end of the cable on both sides.

Step 3: Untwist and Arrange the Wires

Inside the jacket are four twisted pairs of wires (8 total). Untwist the pairs and straighten them.

Then, arrange them in either T-568A or T-568B wiring order. Use the same standard on both ends.

T-568A Wiring Order:

1. White/Green
2. Green
3. White/Orange
4. Blue
5. White/Blue
6. Orange
7. White/Brown
8. Brown

T-568B Wiring Order (Most Common in North America):

1. White/Orange
2. Orange
3. White/Green
4. Blue
5. White/Blue
6. Green
7. White/Brown
8. Brown

Lay the wires flat and keep them in the correct order. Finally, flatten them gently with your thumb for easier insertion.

Step 4: Trim Wires to Length

For non-passthrough connectors, trim the wires so that they are just long enough to reach the end of the connector when inserted. Cut them evenly so they line up perfectly.

For passthrough connectors, leave them a bit longer since the ends will protrude and be trimmed after crimping.

Step 5: Insert Wires Into the RJ45 Connector

Slide the wires into the connector carefully, ensuring they remain in the correct order. Push firmly until:

• Each wire reaches the very end of the connector.
• The outer jacket passes the strain relief tab for a strong connection.

For passthrough connectors, the wires should stick out slightly from the other side.

As soon as you confirm the order, you’re ready to crimp.

Step 6: Crimp the Connector

Place the connector into the crimping tool and squeeze firmly until the pins press down into the wires and the strain relief tab locks onto the outer jacket.

Additionally, for passthrough connectors, trim the wire ends flush with the connector after crimping.

Then, repeat this entire process for the other end of the cable!

Step 7: Test Your Cable

Use a cable tester to confirm that all eight wires are connected in the correct order.

The lights on both ends should flash in sequence.

If any wires are misaligned, cut off the connector and repeat the process on that side.

Once confirmed, your custom ethernet cable is ready for use!

Cat6 vs Cat6a vs Cat5e: Which Should You Choose?

Not all Ethernet cables are created equal. Therefore, here’s a quick comparison to help you decide:

Recommendation: Use Cat6 for most home setups, Cat6a if you want to future-proof or need maximum performance for longer runs, and Cat5e only if you already have it on hand or are working with very low-cost builds.

Frequently Asked Questions

Q: Can I mix T-568A on one end and T-568B on the other?
A: Only if you are intentionally creating a crossover cable. Otherwise, use the same wiring standard on both ends.

Q: How long can an Ethernet cable be?
A: Standard twisted-pair Ethernet cables (Cat5e, Cat6, Cat6a) are rated for up to 100 meters (328 feet) in total length. This includes patch cables at both ends. Beyond this length, you may experience signal loss or reduced speeds.

For 10 Gbps on Cat6, keep runs under 55 meters; use Cat6a for longer 10 Gbps runs.

Q: Do I really need a cable tester?
A: While optional, it saves time and frustration by catching miswires before you plug into your network.

Q: Should I ever use CCA cable?
A: No. Instead, always use solid copper cable for performance, safety, and compliance with Ethernet standards.

Troubleshooting Common Issues When Making Ethernet Cables

• Tester Shows Miswired Pair: Re-check wiring order on both ends, re-crimp if needed.
• Cable Doesn’t Click Securely: Ensure the strain relief tab is pressed down properly during crimping. Also ensure that the release tab covers on your strain relief boots aren’t too stiff and pressing down on the release tabs of the RJ45 connectors as a result. You may want to work the rubber of the strain relief boots with your thumbs a bit to stretch and break them in.
• Poor Network Speeds: Test on another device and verify that you’re using solid copper cable, not CCA.

Final Remarks

Learning how to make ethernet cables saves money, eliminates clutter, and gives you full control over your network setup. Whether you’re wiring a home office, building a home lab, or just need a few short patch cables, this DIY approach is a game changer.

Practice a few times and you’ll be making professional-quality network cables in minutes!

If you prefer a video guide, you can watch my video guide below.

The post How to Make Ethernet Cables: A Complete Step-by-Step Guide appeared first on TechOpt.

In this guide, I’ll walk you through enabling GPU passthrough in Proxmox (or Jellyfin) LXC step by step.

Step 1: Enabling PCI(e) Passthrough in Proxmox

The first step is enabling PCI passthrough at the Proxmox host level. I mostly followed the official documentation here: Proxmox PCI Passthrough Wiki.

I’ll summarize what should be done below.

Enable IOMMU in BIOS

Before you continue, enable IOMMU (Intel VT-d / AMD-Vi) in your system’s BIOS. This setting lets GPUs pass directly through to containers or VMs.

Each BIOS Is different, so if you’re not sure you should check your motherboard’s instruction manual.

Enable IOMMU Passthrough Mode

Not all hardware supports IOMMU passthrough, but if yours does you’ll see a big performance boost. Even if your system doesn’t, enabling it won’t cause problems, so it’s worth turning on.

Edit the GRUB configuration with:

nano /etc/default/grub

Locate the GRUB_CMDLINE_LINUX_DEFAULT line and add:

iommu=pt

Intel vs AMD Notes

• On Intel CPUs with Proxmox older than v9 (kernel <6.8), also add: intel_iommu=on
• On AMD CPUs, IOMMU is enabled by default.
• On Intel CPUs with kernel 6.8 or newer (Proxmox 8 updated or Proxmox 9+), you don’t need the intel_iommu=on parameter.

With an AMD CPU on Proxmox 9, my file looked like this in the end:

Save the file by typing CTRL+X, typing Y to confirm and then Enter to save.

Then update grub by running:

update-grub

Load VFIO Kernel Modules

Next, we need to load the VFIO modules so the GPU can be bound for passthrough. Edit the modules file with:

nano /etc/modules

Add the following lines:

vfio
vfio_iommu_type1
vfio_pci

My file looked like this in the end:

Save and exit, then update initramfs:

update-initramfs -u -k all

Reboot and Verify

Reboot your Proxmox host and verify the modules are loaded:

lsmod | grep vfio

You should see the vfio modules listed. This is what my output looks like:

If you don’t get any output, the kernel modules have not loaded correctly and you probably forgot to run the update-initramfs command above.

To double-check IOMMU is active, run:

dmesg | grep -e DMAR -e IOMMU -e AMD-Vi

Depending on your hardware, you should see confirmation that IOMMU or Directed I/O is enabled:

Step 2: Finding the GPU Renderer Device Path

Now that PCI passthrough support is enabled, the next step is to figure out the device path of the renderer for the GPU you want to pass through.

Run the following on your Proxmox host:

ls /dev/dri

This will print all the detected GPUs. For example, my output looked like this:

by-path  card0  card1  renderD128  renderD129

If you only have a single GPU, you can usually assume it will be something like renderD128. But if you have multiple GPUs (as I did), you’ll need to identify which renderer belongs to your Intel Arc card.

First, run:

lspci

This will list all PCI devices. From there, I found my Intel Arc GPU at 0b:00.0:

Next, run:

ls -l /dev/dri/by-path/

My output looked like this:

lrwxrwxrwx 1 root root  8 Aug 24 11:54 pci-0000:04:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Aug 24 11:54 pci-0000:04:00.0-render -> ../renderD129
lrwxrwxrwx 1 root root  8 Aug 24 11:54 pci-0000:0b:00.0-card -> ../card1
lrwxrwxrwx 1 root root 13 Aug 24 11:54 pci-0000:0b:00.0-render -> ../renderD128

From this, I confirmed that my Intel Arc GPU was associated with renderD128. That means the full device path I need to pass to my LXC container is:

/dev/dri/renderD128

Step 3: Passthrough GPU Device to the Plex LXC Container

Now that we know the correct device path, we can pass it through to the LXC container.

1. Stop the container you want to pass the GPU into.
2. In the Proxmox web UI, select your Plex LXC container.
3. Go to Resources.
4. At the top, click Add → Device Passthrough.
   
5. In the popup, set Device Path to the GPU renderer path you identified in Step 2 (in my case, /dev/dri/renderD128).
6. In the Access mode in CT field, type:0666
   
7. Click Add.
8. Once added, you can start the container again.

A Note About Permissions

Normally, you would configure a proper UID or GID in CT for the render group inside the container so only that group has access. However, in my testing I wasn’t able to get the GPU working correctly with that method.

Using 0666 permissions allows read/write access for everyone. Since this is a GPU device node and not a directory containing files, I’m not too concerned, but it’s worth noting for anyone who takes their Linux permissions very seriously.

Step 4: Installing GPU Drivers Inside the LXC Container

With the GPU device passed through, the container now needs the proper drivers installed. This step varies depending on the Linux distribution you’re running inside the container.

Some distros may already include GPU drivers by default. But if you reach Step 5 and don’t see your GPU as an option in Plex (or Jellyfin), chances are you’re missing the driver inside your container.

In my case, I’m using a Debian container, which does not include Intel Arc drivers by default. Here’s what I did:

1. Edit your apt sources to enable the non-free repo: nano /etc/apt/sources.list
2. Add non-free to the end of each Debian repository line:
   
3. Refresh apt sources: apt update
4. Install the Intel Arc driver package: apt install intel-media-va-driver-non-free
5. Restart the container.

For Debian, I followed the official documentation here: Debian Hardware Video Acceleration Wiki.

Note: These steps will vary depending on your GPU make, model and container distribution. Make sure to check the official documentation for your hardware and distro.

Step 5: Enabling Hardware Rendering in Plex

Now that your GPU and drivers are ready, the final step is to enable hardware transcoding inside Plex.

1. Open the Plex Web UI.
2. Go to Settings (top-right corner).
3. In the left sidebar, scroll down and click Transcoder under Settings.
4. Make sure the following options are checked:
   • Use hardware acceleration when available
   • Use hardware-accelerated video encoding
5. Under Hardware transcoding device, you should now see your GPU. If not, double-check Step 4. In my case, it showed up as Intel DG2 [Arc A380]
6. Select your GPU and click Save Changes.

Testing Hardware Transcoding

To verify that hardware transcoding is working:

1. Play back any movie or TV show.
2. In the playback settings, change the quality to a lower resolution that forces Plex to transcode:
   
3. While it’s playing, go to Settings → Dashboard.
4. If the GPU is handling transcoding, you’ll see (hw) beside the stream being transcoded:
   

That’s it! You’ve successfully set up GPU passthrough in Proxmox LXC for Plex. These same steps should also work for Jellyfin with minor adjustments for the Jellyfin UI.

The post GPU Passthrough to Proxmox LXC Container for Plex (or Jellyfin) appeared first on TechOpt.

You can test or use Tails OS securely on your computer with this method, and nothing saves after you power off the virtual machine.

Step 1: Download Tails OS ISO

First, download the latest Tails OS ISO file from the official Tails website.

The ISO is found under the Burning Tails on a DVD section. Even though you aren’t burning a DVD, you need to use the ISO file for VirtualBox because VirtualBox boots operating systems from CD/DVD images.

The default Tails OS download on the homepage is a .img file for USB sticks, which supports persistence. However, VirtualBox cannot use persistence and does not support virtual USB drives via .img files, so always choose the ISO.

Step 2: Create a New Virtual Machine for Tails OS in VirtualBox

Open VirtualBox and click on New to create a new virtual machine.

Name and Operating System

Give your VM a name, such as Tails OS.

Select the Tails OS ISO file you downloaded as the ISO Image.

Ensure the following settings are automatically detected, and set them if not:

• Set the type to Linux
• Set the subtype to Debian
• Set the version to Debian (64-bit)

Be sure to check Skip Unattended Installation. This is very important for Tails OS because you want to prevent VirtualBox from creating a default user account or setting a password. Tails OS boots directly into its own secure environment by design.

Hardware

The technical minimum for Tails OS is 2048 MB RAM and 1 CPU core. However, for a smoother experience, I recommend:

• Setting the base memory (RAM) to 4096 MB
• Setting processors to 2 CPU cores or more, if your system allows

Hard Disk

Under the Hard Disk section, select Do Not Add a Virtual Hard Disk.

This setup ensures it’s physically impossible to save anything inside the Tails OS virtual machine. When you stop the VM, you erase everything, keeping your session private and secure.

When you’re happy with your virtual machine settings, click Finish.

Step 3: Boot and Use Tails OS in VirtualBox

Start your virtual machine. Tails OS will boot from the ISO.

Set your language and keyboard layout settings, and click Start Tails.

Tails OS will ask you how you want to connect to the Tor network. If you’re not sure, I suggest choosing Connect to Tor automatically and clicking Connect to Tor.

That’s it! Launch the Tor browser and start browsing the web anonymously from Tails OS.

Now you can use Tails OS in VirtualBox safely, knowing that all your activities are wiped when you shut down the VM!

Remarks

• Nothing will be saved when you shut down the virtual machine. Tails OS booted from the ISO does not support persistence. If you need persistence (the ability to save files or settings between sessions), you should use the default USB installation method instead.
• Do not install VirtualBox Guest Additions. Guest Additions can expose parts of your host system to the virtual machine, which goes against Tails OS’s privacy goals. Besides, when you power off the VM, it will wipe Guest Additions anyway.
• Keep the ISO file. Do not delete the ISO file you downloaded, because your virtual machine will need it every time it boots Tails OS.
• Use open-source virtualization software. Tails OS recommends using open-source virtualization tools like VirtualBox or KVM to run Tails OS because their transparency and auditability align with Tails OS’s privacy philosophy. Proprietary alternatives (such as VMware) are not as easily audited for privacy.
• The Tails OS documentation advises against using VirtualBox because it gets stuck at 800×600 resolution. I’ve found this advice seems outdated. You can set a variety of screen resolutions from the Tails OS display settings menu by right-clicking the desktop. VirtualBox runs Tails OS very well and is a much easier open-source alternative to KVM.

If you prefer a video guide, you can follow along with the video below:

The post How to Run Tails OS in VirtualBox appeared first on TechOpt.

In this guide, you’ll discover how to set a static IP in Ubuntu and define custom DNS settings, including nameservers and search domains. Additionally, we’ll explain how to keep DHCP while specifying DNS servers for better control.

Why Should You Set a Static IP on Ubuntu Server?

Assigning a static IP ensures your server retains the same address across reboots. This reliability is essential for servers running web services, databases, or acting as internal network resources.

Step 1: Identify Your Ubuntu Server Network Interface

To begin, list your network interfaces:

ip link

You’ll usually see names like eth0, ens33, or enp0s3.

Step 2: Edit the Netplan Configuration

Netplan configurations are stored in /etc/netplan/. View the files with:

ls /etc/netplan/

Next, edit the YAML file (replace with your actual file name):

sudo nano /etc/netplan/50-cloud-init.yaml

Here’s an example static IP configuration for Ubuntu Server:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: no
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        search: [yourdomain.local]
        addresses:
          - 1.1.1.1
          - 1.0.0.1

Replace eth0 with your interface name. Adjust the IP, gateway, and DNS to match your network.

Important: Some older guides might mention using the gateway4 parameter. However, gateway4 has been deprecated. It’s better to use the routes section, as demonstrated above, for better compatibility with future Ubuntu versions.

Step 3: Apply the Static IP Ubuntu Configuration

Once you have finished editing, apply the changes with:

sudo netplan apply

To confirm your new settings, run:

ip a

This command will display your active IP address. To confirm your DNS configuration is working, you can run:

apt update

This will refresh the built-in software repositories, and as long as it’s successful you know that your DNS configuration is working.

Alternative: Keep DHCP but Configure DNS in Ubuntu Server

If you prefer to use DHCP for IP assignment but still want to control DNS servers, use this configuration:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: yes
      dhcp4-overrides:
        use-dns: no
      nameservers:
        search: [yourdomain.local]
        addresses:
          - 1.1.1.1
          - 1.0.0.1

This method allows the server to receive its IP address from the DHCP server, while your specified DNS servers handle name resolution.

Conclusion

To sum up, netplan is the modern, recommended tool for configuring a static IP Ubuntu setup. You should avoid older methods like resolvconf or editing /etc/network/interfaces, as they are deprecated in the latest Ubuntu versions. Whether you need a full static IP or simply want to control your DNS while keeping DHCP, netplan makes the process clear and manageable.

If you would like to learn about all the configuration options for netplan, you can read the official Netplan documentation.

If you would prefer to view this guide in video form, I’ve created a video explaining these instructions on the TechOpt.io YouTube channel, which you can watch below:

The post Setting a Static IP Address and DNS in Ubuntu Server appeared first on TechOpt.

Using RTL-SDR and rtl_433 for Water Meter Home Assistant Integration

After reading success stories online, I picked up the Nooelec RTL-SDR v5 Bundle from Amazon. This little USB SDR dongle can tune from 100kHz to 1.75GHz, which is perfect for picking up utility meter signals.

My first attempt was to plug the SDR into my Raspberry Pi 4 running Home Assistant and use the rtl_433 addon. Unfortunately, I ran into some power issues and weird addon errors, likely due to the antenna drawing too much power with everything else I already had plugged in.

Setting Up a Dedicated SDR Host for Home Assistant

To fix this, I decided to run the SDR on a dedicated Raspberry Pi. I had an old, original Pi 1 Model B lying around. With a decent 2A power supply and a wireless N dongle for network connectivity, I installed Raspbian Lite and the rtl_433 tool.

I experimented with both 433 MHz and 915 MHz frequencies, using the coiled antennas included in the kit. The 900 MHz antenna ended up being the winner. On the 915 MHz band, I finally started seeing data in the logs:

Identifying My Water Meter in Home Assistant Logs

One key data point stood out: a field called Consumption Data showing a value around 168000. After comparing this with the value on my actual Neptune T-10 water meter (used by the City of Ottawa), I realized I was picking up my own water meter’s signal!

I also saw signals from neighboring meters, but by monitoring the data for a few hours, I confirmed which one was mine. The value updated every 15 to 30 minutes.

Fixing USB Stability for Water Meter Data Collection

One hiccup: after several hours, rtl_433 would crash with libusb errors. Unplugging and replugging fixed it temporarily, but the long-term solution was to use a powered USB hub (4A supply) to give the SDR the juice it needed. I also ditched the USB extension cable from the kit and plugged the SDR directly into the hub. That seemed to fix the issue.

The nice thing with this hub is also that I can use it to power the Pi; so I have 1 power cable for the hub, with 1 USB cable running from the hub to the Pi. I have a microUSB cable going from the hub to the Pi for power, and I have the RTL-SDR and Wi-Fi dongle plugged into the USB hub. You can see the final setup up close in the picture below:

Publishing Water Meter Data to Home Assistant via MQTT

With the setup stable, I configured rtl_433 to output data to MQTT. Since I already had the Mosquitto addon running in Home Assistant, I pointed rtl_433 to it and monitored the output using MQTT Explorer. I found the data for my meter which matched up to the logs I was seeing directly on the Pi:

Creating a Systemd Service for Water Meter Integration

To make everything persistent, I created a systemd service at /etc/systemd/system/ha-sdr-915M.service:

[Unit]
Description=rtl_433 on 915M SDR
After=network.target

[Service]
ExecStart=/usr/local/bin/ha-sdr-915M.sh
Restart=unless-stopped
WorkingDirectory=/usr/local/bin

[Install]
WantedBy=multi-user.target

The script at /usr/local/bin/ha-sdr-915M.sh:

#!/bin/bash

source /etc/ha-sdr.env

LOGFILE="/var/log/ha-sdr/ha-sdr-915M.log"

/usr/bin/rtl_433 -f 915M -F mqtt://homeassistant.domain.com:1883,user=$MQTT_USER,pass=$MQTT_PASS -F kv 2>&1 | while IFS= read -r line
do
    echo "$(date '+%Y-%m-%d %H:%M:%S') $line"
done >> "$LOGFILE"

I enabled the service by running systemctl daemon-reload and systemctl enable ha-sdr-915M.service.

Adding a Water Meter MQTT Sensor in Home Assistant

In Home Assistant YAML configuration:

sensor:
  - name: "Water Meter Consumption Data"
    object_id: water_meter_consumption_data
    state_topic: "rtl_433/pisdrfrontoh/devices/ERT-SCM/33391039/consumption_data"
    unit_of_measurement: "gal"
    state_class: total_increasing
    device_class: water

I noticed the values from my meter were in gallons, even though I’m in Canada where cubic meters or litres are common. To convert to litres, I added a template sensor:

sensor:
  - name: "Water Meter Consumption (Litres)"
    state: >
      {{ states('sensor.water_meter_consumption_data') | float * 3.78541178 | round(2) }}
    unit_of_measurement: "L"
    device_class: water

Setting Up a Utility Meter for Daily Water Tracking

Finally, I created a utility meter entity to track daily water usage:

utility_meter:
  daily_water:
    source: sensor.water_meter_consumption_litres
    cycle: daily

This entity allowed me to graph and display daily water usage data directly from my water meter in Home Assistant:

Final Thoughts on Monitoring My Water Meter with Home Assistant

This project took a few days of tuning and monitoring, but I’m thrilled with the results. For now, I’m only picking up water meter data, but I’m hopeful I’ll find more signals soon.

If you’re thinking about tracking your water meter in Home Assistant, using an SDR like the Nooelec RTL-SDR v5 and rtl_433 software is a great DIY approach. The insight into water usage is already super useful!

The post Reading my Water Meter in Home Assistant with USB SDR appeared first on TechOpt.

Step 1: Identify the USB Drive

Before writing the ISO to USB in Linux, you need to determine the correct device name for your USB drive. Plug in the USB drive and run:

sudo fdisk -l

This command lists all storage devices connected to your system. Look for your USB drive by checking the model, size and type. It will usually be listed as /dev/sdX (e.g., /dev/sdb) or /dev/diskX (on some distributions).\

In my case, this happens to be /dev/sdc, as you can see in the screenshot below:

Warning: Be very careful when selecting the device name, as writing to the wrong disk will result in data loss!

Step 2: Write the ISO to the USB Drive

Once you’ve identified the correct device, use the dd command to write the ISO to the USB drive:

sudo dd if=/path/to/iso.iso of=/dev/sdX bs=1M

Replace /path/to/iso.iso with the actual path to your ISO file and /dev/sdX with your USB drive’s identifier.

Explanation of Parameters:

• if=/path/to/iso.iso – Input file (the ISO image).
• of=/dev/sdX – Output file (your USB drive). Do not include a partition number (e.g., /dev/sdX1), as you need to write to the whole disk.
• bs=1M – Block size (1 Megabyte). Without this, dd defaults to a 512-byte block size, which can significantly down the process.

Step 3: Monitor Progress

When the dd command completes, it will output a summary similar to this:

123456789+0 records in
123456789+0 records out
123456789 bytes (X GB) copied, XX.XXXX s, XX.X MB/s

This confirms that all data has been written successfully to the USB drive:

The dd command does not provide real-time progress updates by default. On some distributions, you can add status=progress to see the write progress:

sudo dd if=/path/to/iso.iso of=/dev/sdX bs=1M status=progress

Step 4: Safely Eject the USB Drive

Once the process is complete, ensure all data is written by running:

sudo sync

Then, safely remove the USB drive:

sudo eject /dev/sdX

Remarks

• For bigger ISO images, the process will take longer.
• You should use the root device name (e.g., /dev/sdX) and not a partition (e.g., /dev/sdX1).
• For all options you can use with dd, you can consult the dd man page.

Now, your USB drive is ready to boot into the written ISO image!

If you would like a video guide, I also have one available:

The post How to Write an ISO to USB Drive in Linux appeared first on TechOpt.

Why Use Custom Warnings in Zabbix?

Zabbix provides various alerts by default, but I needed a custom warning to:

• Ensure Btrfs snapshots are being created regularly
• Get notified if the snapshot process fails
• Integrate this check into my existing monitoring system

There are numerous various use-cases for custom warnings in Zabbix. Custom warnings provide greater flexibility, allowing you to adapt them to your specific monitoring needs.

Setting Up a Custom Warning in Zabbix

1. Create a Custom Script

First, I created a dedicated directory for custom scripts in Zabbix on my Linux host:

mkdir -p /etc/zabbix/scripts

Then, I created the script file and opened it for editing:

nano /etc/zabbix/scripts/check_btrfs_snapshot.sh

I added the following script to check if a Btrfs snapshot exists within the last 24 hours:

#!/bin/bash

SNAPSHOT_DIR="/mnt/btrfs/.snapshots"  # Adjust to your snapshot location
THRESHOLD=$(date -d '24 hours ago' +%s)

latest_snapshot=$(find "$SNAPSHOT_DIR" -maxdepth 1 -type d -printf '%T@ %p\n' | sort -nr | head -n1 | awk '{print $1}')

if [[ -z "$latest_snapshot" ]]; then
    echo 0  # No snapshots found
elif (( $(echo "$latest_snapshot >= $THRESHOLD" | bc -l) )); then
    echo 1  # Recent snapshot exists
else
    echo 0  # No recent snapshot
fi

After saving the script, I made it executable:

chmod +x /etc/zabbix/scripts/check_btrfs_snapshot.sh

2. Add the Script to Zabbix Agent 2

I’m using Zabbix Agent 2 for advanced features. Since Zabbix Agent 2 supports system.run, I modified zabbix_agent2.conf to add the script:

1. Open the configuration file: nano /etc/zabbix/zabbix_agent2.conf
2. Add this line to allow the script: AllowKey=system.run[/etc/zabbix/scripts/check_btrfs_snapshot.sh]
3. Restart the agent: systemctl restart zabbix-agent2

3. Create a Custom Item in Zabbix

1. Go to Zabbix Web Interface → Monitoring → Hosts
2. Select the host where Btrfs is monitored (or where you’re adding your custom script) and click Items.
3. Click Create Item and set your parameters:
   • Name: Btrfs Snapshot in the last 24 hours
   • Type: Zabbix Agent
   • Key: system.run[/etc/zabbix/scripts/check_btrfs_snapshot.sh]
   • Type of information: Text
   • Update interval: 30m

I also recommend testing your script to make sure it runs properly with the Test option at the bottom of the Item UI from above.

4. Set Up a Custom Trigger

1. Navigate to the Triggers tab.
2. Click Create Trigger.
3. Use this expression to trigger a warning if no snapshot exists in the last 24 hours:last(/example-hostname/system.run[/etc/zabbix/scripts/check_btrfs_snapshot.sh])=0.
   You can also use the “Add Condition UI” in the side panel by clicking Add to help generate the correct expression.
4. Set severity (e.g., Warning).
5. Click Add.

Final Thoughts

Setting up this custom warning in Zabbix ensures my Btrfs snapshots are created on schedule. If a snapshot fails, I get a warning immediately, allowing me to troubleshoot the issue before it becomes a bigger problem.

If you’re using Zabbix for monitoring, creating custom warnings like this can significantly improve your ability to track and respond to important system events. Try it out and enhance your monitoring experience!

The post How to Create a Custom Warning in Zabbix appeared first on TechOpt.

Why Upgrade Now?

Ubuntu LTS (Long-Term Support) versions receive five years of updates, meaning 20.04 will stop receiving standard support in April 2025. While Ubuntu does offer Extended Security Maintenance (ESM) for an additional five years, that requires an Ubuntu Pro subscription, which costs money and may not be ideal for all users.

Checking Software Compatibility Before Upgrading

One of the main reasons I stayed on Ubuntu 20.04 was because I run the TP-Link Omada Controller, which historically ran best on older LTS versions. However, as of now, Omada supports Ubuntu 22.04 LTS, making this a good time to upgrade.

If you’re running custom software, self-hosted services, or enterprise applications, check their documentation or forums to confirm compatibility before proceeding.

Steps to Upgrade from Ubuntu 20.04 LTS to 22.04 LTS

To ensure a smooth upgrade, follow these steps:

1. Back Up Your System

Before making major changes, always back up important data. If you’re running a production server, consider creating a full system snapshot using tools like:

• Timeshift (for desktop users)
• rsync or tar for manual backups
• Btrfs snapshots (if you’re using a Btrfs filesystem)

I also backed up my Omada configuration through the web administration page, as well as made a snapshot of the virtual machine in Proxmox.

2. Update Ubuntu 20.04 Fully

Before upgrading, ensure your system is fully up to date. Run the following commands:

sudo apt update && sudo apt upgrade -y
sudo apt full-upgrade -y
sudo apt autoremove --purge -y

After the updates complete, reboot your system:

sudo reboot

3. Start the Upgrade Process

Once back online, use the following command to begin the upgrade:

sudo do-release-upgrade

This will check for a new release and guide you through the upgrade process.

4. Follow the On-Screen Prompts

• The upgrade tool will download necessary packages and warn you about changes.
• If prompted to replace configuration files, choose the default option unless you’ve manually customized them.
• When prompted to remove obsolete packages, confirm with Y.
• The process may take some time depending on your internet speed and system resources.

5. Reboot Into Ubuntu 22.04

After the upgrade is complete, reboot your system:

sudo reboot

Once your system boots up, confirm the upgrade with:

lsb_release -a

This should display Ubuntu 22.04 LTS.

Post-Upgrade Checks

1. Verify Software Functionality – Ensure your applications and services, like the TP-Link Omada Controller, are running properly.
2. Check for Remaining Updates – Run: sudo apt update && sudo apt upgrade -y
3. Remove Old Packages – Clean up unnecessary files: sudo apt autoremove --purge -y

Conclusion

Upgrading from Ubuntu 20.04 LTS to 22.04 LTS is straightforward but requires some preparation. Since Ubuntu 20.04 reaches EOL in April 2025, it’s best to upgrade sooner rather than later to stay secure and supported. If you run software that relies on very specific versions on Ubuntu (such as the TP-Link Omada Controller), ensure it’s compatible before proceeding.

The post Upgrade Ubuntu 20.04 LTS to 22.04 LTS appeared first on TechOpt.

A key advantage of using Btrfs on openSUSE is its integration with Snapper, a tool that automatically creates snapshots before critical system changes, such as package installations through YaST or zypper. This allows users to quickly rollback openSUSE if something goes wrong.

While openSUSE is known for its strong Btrfs integration, the filesystem is not exclusive to it. Other Linux distributions, such as Fedora, Ubuntu, and Arch Linux, also support Btrfs, though the level of integration varies.

In this guide, we’ll explore how Btrfs works in openSUSE, how automatic snapshots function, and how to manually create and restore snapshots when needed.

Automatic Snapshots in openSUSE

openSUSE, through Snapper, automatically creates Btrfs snapshots before major system changes. These snapshots act as a safety net, allowing you to rollback openSUSE to a working system state if something breaks.

For example, when installing or updating software via YaST or zypper, a snapshot is taken before the changes are applied. This means that if an update causes issues, you can easily revert to the state before the update.

To list all available snapshots, run:

snapper list

You’ll see a list of snapshots with IDs, timestamps, and descriptions of what triggered them.

Creating a Manual Snapshot

While automatic snapshots provide great protection, there may be times when you want to create a manual snapshot before making significant changes.

To create a new snapshot manually, run:

sudo snapper create --description "Before major change"

This will create a snapshot that you can revert to if necessary. You can confirm its creation by running snapper list.

Rollback openSUSE to a Snapshot

If something goes wrong after an update or system change, rolling back to a previous snapshot is straightforward. You can do this in two ways: using Snapper or from the GRUB boot menu.

Method 1: Rollback via Snapper (Live System)

To rollback openSUSE to a previous snapshot while still inside your running system, first identify the snapshot ID from snapper list, then run:

sudo snapper rollback <snapshot-ID>

For example, if you want to rollback to snapshot 20, you would run:

sudo snapper rollback 20

After rolling back, reboot your system to apply the changes:

sudo reboot

Method 2: Rollback via GRUB

If your system becomes unbootable after an update or change, you can rollback openSUSE from the GRUB menu:

1. Reboot your computer.
2. In the GRUB menu, select Advanced options for openSUSE.
3. Choose Start bootloader from a snapshot.
4. Select a snapshot from the list and boot into it.
5. If the system works fine in this snapshot, you can make it permanent by running:sudo snapper rollback sudo reboot

This will set the selected snapshot as the new baseline.

Btrfs and Snapper Make a Rollback in openSUSE so Easy!

Btrfs, combined with Snapper, provides openSUSE users with a robust and reliable way to manage system changes, and rollback if necessary. Automatic snapshots ensure that package updates and system modifications can be easily undone if needed, and manual snapshots give users additional control over their system state.

Although Btrfs is especially well-integrated in openSUSE, it is also available on other Linux distributions like Fedora and Ubuntu. However, openSUSE’s implementation with Snapper makes it one of the most user-friendly and reliable choices for those looking to take full advantage of Btrfs.

The post Rollback openSUSE with Btrfs: A Filesystem with Snapshots appeared first on TechOpt.