SMART Monitoring:
This is a baffling change. TrueNAS is a NAS (Network Attached Storage) operating system. Data integrity is important for NAS users, it is important enough that TrueNAS has a “Data Protection” tab (which was where SMART tests used to be scheduled, before that section was removed in the 25.10 update).
SMART tests have their flaws, even so they can be very valuable and were used by many TrueNAS users, including me! One of the reasons I liked using TrueNAS was how easy it was to schedule SMART tests and ZFS scrub tasks.
SMART (Self-Monitoring, Analysis and Reporting Technology) is the drive’s built-in health reporting. It exposes attributes (error counters, temps, reallocated/pending sectors, etc.) and can run self-tests on demand.
The two tests most people schedule are:
SMART tests don’t replace ZFS scrubs (scrubs verify data end-to-end), but they’re still useful as an early warning system for drives that are slowly going bad.
Technically, iXsystems did not remove any SMART functionality from the system, only a UI section. SMART tests can still be scheduled using cron, though it is more cumbersome. For such a critical task, I appreciate having a UI that explains when tests are scheduled and makes it easy to schedule them at different times.
Indeed, the SMART UI in TrueNAS was never great. For as much as I avoid using TrueNAS apps (for reasons such as TrueNAS having broken every single app in the past when they moved from Kubernetes to Docker), the one app I always install is Scrutiny. It explains the SMART results better than any other app that I have found. Nevertheless, I take issue with the recommendation to use it as if it’s an alternative (“Users seeking advanced SMART monitoring can install the “Scrutiny” app from the TrueNAS catalog, which offers superior disk health tracking with historical data storage, customizable alerts, and automatic drive detection”). Scrutiny is great at displaying SMART results, however it does not schedule the tests itself. Scrutiny is also seeking new maintainers. What would’ve been nice was if instead of just pointing users to a third-party app, iXsystems would have stepped up and contributed to Scrutiny, acknowledging the things it does better than TrueNAS itself while also working to bring a better SMART UI to TrueNAS. Notably, iXsystems have contributed back to OpenZFS.
What was perhaps more infuriating than the decision itself was the stubbornness in ignoring the community feedback that followed. A feature request to Bring back SMART scheduling to UI was opened on the Feature Requests section on the TrueNAS forums, stating “Literally no one approves this change. Bring it back.”. The feature request gained significant traction: it received 121 votes and 110 responses. In the end, after internal discussion, the feature was denied (with explanations that many users didn’t find convincing).
If this doesn’t prove that iXsystems doesn’t care about community feedback, I don’t know what does. So much for TrueNAS “Community Edition”.
I have been using TrueNAS for several years, since the release of TrueNAS SCALE in 2022 (which has since been renamed to TrueNAS Community Edition). I have maintained scripts that help install TrueNAS on Proxmox VE. To this day, TrueNAS remains a critical part of my homelab.
Of course there are alternatives. Before I moved to TrueNAS, I was using OpenMediaVault (OMV). I have high praise for that project, and unlike TrueNAS and Unraid, OMV is community-driven with no profit motives (donations are accepted). The main reason I moved to TrueNAS at the time was the native ZFS integration. OMV relies on a plugin to enable ZFS. It works, but I preferred a system that’s designed to work with ZFS from the get-go (I was able to export my ZFS pool from OMV and import it into TrueNAS with no data loss).
These days, if I were to move away from TrueNAS, I will likely go the DIY route instead. When I think of what I use TrueNAS for, all I really need is a system that supports ZFS, NFS/SMB data shares, SMART tests and Scrutiny. I am currently experimenting with a NixOS installation that does all of that in one declarative configuration.
Nevertheless, for now I plan to stay with TrueNAS (at least until I finish examining NixOS for this purpose). I will continue using TrueNAS for the time being, ensure SMART tests are still scheduled in cron, as well as continue using Scrutiny.
There is value in having a curated and tested NAS distribution, even if I don’t agree with all of their decisions. I am reminded of the time that Linus Sebastian lost a petabyte of data, due to having manually configured ZFS on CentOS without data scrubbing. In TrueNAS, data scrubbing is configured by default to run automatically, and at least the scheduling UI for that has not been removed.
I have been considering different options for hosting static-sites for free. In my personal notes, I previously wrote about three differenet services for static website hosting: GitHub Pages, Cloudflare Pages and Codeberg Pages. Two of these options now have more modern alternatives: Grebedoc instead of Codeberg Pages and Cloudflare Workers instead of Cloudflare Pages.
Although Cloudflare Pages is still around, since 2023 Cloudflare has been merging some of the features into Workers. Nowadays, while both Pages and Workers can be used, Workers is the preferred option (Migrate from Pages to Workers · Cloudflare Workers docs). Workers now has all the same static asset hosting features as Pages, plus additional features.
In terms of pricing, Workers & Pages Pricing | Cloudflare lists the prices for both Workers and Pages. At first glance, the Workers Free tier appears to be more limited than Pages Free tier. Pages Free boasts “Unlimited sites”, “Unlimited requests” and “Unlimited bandwidth”, while Workers Free says “Includes 100k requests per day”, which is a far cry from “unlimited”. However, delving into the Cloudflare Worker docs, reveals the distinction:
Therefore, my understanding is that Cloudflare Workers is free and unlimited for static assets, and only costs money with requests to Worker scripts (importantly, clients loading static assets do not count as “requests”). This is essentially the same as Cloudflare Pages pricing, it only starts to potentially cost money if you go beyond what Pages can do and into other Worker features.
Despite today’s outage, I find Cloudflare to be generally reliable and use its free tier for most of my self-hosted websites and services. The only thing I pay for is domain registration, and domains are fairly priced (offered at cost). Many people have concerns over Cloudflare’s control of the web. I understand those concerns but it’s not something that I personally worry about. I enjoy taking advantage of their generous free tier either way.
Because I already use Cloudflare as my domain registrar, it makes sense to also take advantage of their static website hosting features and the included unlimited traffic.
Both Cloudflare Pages and Workers have less limitations than GitHub Pages. The most notable limitation of GitHub Pages that I can find is that the free tier of GitHub Pages and wikis only allows using “Public repositories”.
Self-hosting a website is possible as I have the infrastructure for it at home. After I completed the bootcamp, I kept my final project (PetInvent) up for several months on a self-hosted Docker Compose stack (PetInvent + PostgreSQL + nginx), which was running on my homelab along my other other self-hosted services. However, I don’t have the same uptime as Cloudflare. And even if I did, I still rely on Cloudflare anyway (Tunnels + domain), even for self-hosting. I might as well use their hosting as well if it doesn’t cost me anything.
Some relevant pages from Cloudflare Workers docs:
Cloudflare Workers docs have guides for various frameworks which I am using or considering using, including React + Vite and Docusaurus. These guides can either be followed directly, or npm create cloudflare@latest can help bootstrap a project for various frameworks with correct Workers configurations.
Based on the docs, Cloudflare Workers may be ideal for CALMe, which uses React + Vite for the frontend and Docusaurus for the documentation. My current goal is to set up a Continuous Deployment for CALMe, with the main branch deploying live to my FQDN on Cloudflare using Cloudflare Workers. After I get main working, I can setup a fancier CD flow with previews on pull requests.
For my personal website, I was leaning towards using Hugo, which works with Cloudflare Workers.
Featured image by Sharad Bhat on Unsplash.
]]>This Helm chart bootstraps a Home Assistant instance on Kubernetes, supports configurable persistence, controller types, add-ons (e.g. code-server), and is auto-updated with new Home Assistant releases.
For over two years, I have been running Home Assistant on Home Assistant Green, which comes pre-installed with Home Assistant OS.
The device has been working perfectly well for all of my smart home needs. Even though it is not the most cost-effective way to run Home Assistant, it is a well-designed device, fast enough for my needs and power efficient.
If I were buying a new dedicated device for Home Assistant today, I may have preferred to get a mini PC instead, since some mini PCs are similar in price to the HA Green but significantly more powerful (though maybe not as power efficient). However, I would still strive to run Home Assistant with Home Assistant OS.
On recent podcast episodes of Linux Unplugged (including LINUX Unplugged 637: Chris’ Smart Home Disaster), Chris talked about considering a move away from the Home Assistant Yellow (which is more powerful than the HA Green), perhaps towards a mini PC running multiple services (rather than just a mini PC). Chris also debated the benefits of running Home Assistant on NixOS vs Home Assistant OS. Nevertheless, I tend to agree with Chris’s long-standing stance that it’s best to give Home Assistant its own device, because of how essential it can be to a home.
I run all my other self-hosted services in containers. Why not Home Assistant as well? The reason is that Home Assistant OS makes everything easy. Notably, Home Assistant Container installations don’t have access to add-ons.
Add-ons are additional standalone third-party software packages that can be installed on Home Assistant OS. \[Learn more\]
Although Add-ons are really just containers, and many Home Assistant users manage to install them as separate containers, this requires elaborate configurations to make the different containers work together with Home Assistant. Even though I’ve been doing Docker Compose stacks (for example, applications that have multiple containers including a database), the moment I found out that HAOS allows one-click installation of Add-ons, I immediately gravitated towards that simplicity. Some examples of Add-ons that I use and rely on are Matter Server, Zigbee2MQTT and Music Assistant.
Backups are also fairly simple on HAOS.
Nevertheless, I do find the idea of this Home Assistant Helm Chart compelling. Features such as replicas and partial add-ons support make this an interesting alternative to HAOS. I may run a test deployment in my parent’s home, since that’s where my homelab cluster is.
Featured image by Jakub Żerdzicki on Unsplash.
]]>