I’m curious if anyone is thinking about switching over to TrueNAS SCALE, when it’s released next year.
I’m currently using FreeNAS TrueNAS Core because, IMO, it is the best (only?) NAS solution that has native support for zfs. With TrueNAS Scale, that’s (sort of) going to change. Along with being a Debian based OS, there will be support for Kubernetes / Docker. Personally, I’m just getting my feet wet with Docker and I know even less about Kubernetes.
From a non-technical stand point, I’m not so much hung up on if the underlying OS is FreeBSD (Core) or Linux (Scale). For my NAS (home file server) point of use, both Core and Scale are identical, so for me, it comes down to adding extra services to the NAS (plugins)…
The goal of TrueNAS SCALE container services is to provide easy-to-use infrastructure for deploying and managing container workloads on either a single node or a cluster of nodes. The container workloads may be simple Docker containers or a set of complex multi-container Pods that have been custom developed. The REST APIs and web UI for using these services are simple and powerful.
In some cases, users have specific container management tools that they would like to continue using. SCALE allows for this with some reasonable flexibility.
The approach with SCALE to solve this problem is three pronged:
SCALE includes a Kubernetes distribution (K3s) that has been integrated with middleware to provide a simple web UI and REST API for managing containers. Kubernetes will operate first on a single node (later as a cluster) and support Docker containers or Kubernetes pods defined by Helm Charts. This integration will provide an approximation of the Jails and Plugins capability provided by TrueNAS CORE. The initial WebUI for plugins is planned for the 20.12 release.
SCALE allows Kubernetes to be disabled. The user will then have access to the native container services within Debian. This will include Docker, LXC (Q1 2021) or any other Kubernetes distribution. There will be a CSI (Container Storage Interface) that can couple the container services with the SCALE storage capabilities. Users would script these capabilities and then use 3rd party tools like Portainer to manage them. This approach can be used on SCALE 20.10 and later.
SCALE provides very reliable VMs (via KVM) for guest OSes with specific container management features. Users can create these VMs with any OS (including Windows, Linux and FreeBSD) with any software stack they wish. These VMs would allow full integration with existing Container management clusters. This is supported on SCALE 20.10 and later.
It would have have significant advantages to be worthy of me shifting from TrueNAS Core, but I can’t see how it would benefit a home user much, if any. I’ve been using Core for months and have not had a single problem.
PLEASE BEWARE – The 11.3-RELEASE is now past it’s EOL date. This has been causing various issues in several plugins, that are beyond my control. From the limited number of Google results I could find, the solution is upgrading to a supported RELEASE. Basically the packages in the FreeBSD repos have been updated and are no longer compatible with 11.3. Unfortunately for FreeNAS users, ix-systems has no plans for switching the FreeNAS plugins to the 11.4-RELEASE
This leaves two options:
Manually creating an 11.4-RELEASE jail on FreeNAS 11.3
Switch your FreeNAS to the TrueNAS-12.0-Stable train
The suggested solution from ix-systems is upgrading to TrueNAS Core, which will use the 12.1-RELEASE for plugins. After upgrade the NAS itself, any plugin can be upgraded from the TrueNAS console using (also, this will first take a snapshot of the jail)
iocage upgrade $_JAIL_NAME
Then you can use the following to finish the python upgrade for HA
iocage console $_JAIL_NAME
# Press 0 to exit the menu
sysrc homeassistant_python=/usr/local/bin/python3.8
service homeassistant reinstall
Thanks, I upgrade to TrueNAS and then update the jail, but now when I try reinstall command, I get “/srv/homeassistant/bin/hass is not found or is not executable”, did I make something wrong?
The service tries some basic checks, intended to prevent using an existing virtualenv, that was not created for Home Assistant.
Also, /srv/homeassistant is the old location for the virtualenv. (It’s OK if you want to continue using it.) To continue using the current location, please try
iocage console _$JAIL_NAME
# Press 0 to exit the menu
rm -r /srv/homeassistant
service homeassistant install homeassistant
Some months ago, some of the defaults for this plugin were changed to be more FreeBSD like. If you would like to use the new location, please try
iocage console _$JAIL_NAME
# Press 0 to exit the menu
sysrc homeassistant_venv=/usr/local/share/homeassistant
service homeassistant install homeassistant
EDIT: Home Assistant may also need to be (re)started afterwards
Thanks, I try the new localisation to be like everyone but when I try the install I got: “install does not exist in /etc/rc.d or the local startup directories (/usr/local/etc/rc.d), or is not executable”
Did you ever find any solution to this? I am encountering the same thing - trying to run aiosenseme from the jail shell or the truenas shell (or do raw UDP broadcast) results in the same thing. Points to it being a truenas configuration or issue?
I’m going to guess that is something to do with the jails using VNET. Even in my own setup. I’m not sure why some integrations seem to always be detected (brother printers, chrome-cast, wled) but others remain a PIA to get connected (Logitech Harmony and Emulated HUE)
This is one example why I’m curious if anyone is thinking about switching over to TrueNAS SCALE , when it’s released next year. The most obvious reason I wonder about this, is do to the number of available docker contains VS available iocage plugins.
All the Kubernetes stuff is way over my head… but I understand this part
SCALE allows Kubernetes to be disabled. The user will then have access to the native container services within Debian. This will include Docker, LXC (Q1 2021) or any other Kubernetes distribution.
I can already tell you, I have successfully converted a test machine from TrueNAS COREtoSCALE. Since both platforms use the same middle-ware, the web UI is largely the same. I had no trouble importing a zpool (that contained a dataset with my HA configuration) I had previously created on CORE. While SCALE has only released the first ALPHA build, some feature are still incomplete. Among others, there is not yet a UI for managing containers. Still, I was able to install Home Assistant using docker-compose in a matter of minutes. I pointed the /path/to/config at my existing dataset and HA started up the first time, just like I had left it!
Interesting, I’ll have to do some reading on SCALE. Glad your test was so successful - I think in the long run, linux will definitely be easier to work with than BSD.
@jyavenard@troy I dug into this a bit further and it seems that it has to do with the way that BSD handles UDP broadcasts - won’t forward them to multiple interfaces and has some opaque (to me) logic about how they are routed. You can read more here: https://www.freebsd.org/cgi/man.cgi?ip(4) (search for IP_ONESBCAST). I wrote a little python script to broadcast over UDP and then used tcpdump to figure out what the packets looked like. They were sending to 255.255.255.255 - but who knows if they actually made it to a real network interface (see link above). On my Mac (ironically BSD based, but I’m sure this has been addressed), the packets are sent to my default NIC’s subnet (in my case 192.168.1.255), and are broadcast out to all hosts on that subnet.
As a quick and dirty workaround for Haiku SenseMe, you can pop into your jail’s copy of the aiosenseme library and force it to broadcast to a specific subnet’s broadcast ip. Force the subnet by changing
sendto(message, ("<broadcast>", port))
to sendto(message, ("192.168.1.255", port))
in your local copy of aiosenseme (for me it was located in /usr/local/share/homeassistant/lib/python3.8/site-packages/aiosenseme/discovery from the jail shell).
Changing this allowed me to run senseme discovery and found my devices. This hack will probably break any time the integration is updated, and I’m not even sure if it’s required past the discovery phase. Sounds like both of you have found workarounds, but wanted to post this here in case it’s helpful. I think maybe a more robust fix would be for affected integrations to stop relying on the broadcast shortcut and either iterate through network interfaces and send broadcast packets to each individually, or allow the selection of an interface as an option.
edit: quick follow up to note that python doesn’t seem to support the IP_ONESBCAST socket option, even when specified as an integer (I looked it up, it is 23). It’s possible that setting that option if available would fix it. If I’m bored later I’ll try that out in C (or a quick googling shows that Ruby supports it).
Attention FreeNAS users – The FreeBSD 11.3-RELEASE is now past it’s EOL date .
This has been causing various issues for this plugin on FreeNAS , that seem beyond my control. To my understanding, as packages in the FreeBSD repos have been updated, some are no longer compatible with the 11.3-RELEASE. From the limited number of Google results I can find, the solution is upgrading to a supported RELEASE.
I am not able to support using this plugin with the expired 11.3-RELEASE base.
At this time, ix-systems has no plans for switching the FreeNAS plugins to the 11.4-RELEASE and I have not found another way to make a plugin use the next release. - To my knowledge, using the 11.4-RELEASE can only be accomplished by manually creating jail.
This leaves two options:
Manually creating an 11.4-RELEASE jail on FreeNAS 11.3
Switch your FreeNAS to the TrueNAS-12.0-Stable train
There are several people who have opted for upgrading to TrueNAS Core. So far, everyone has been able to restore Home Assistant to full functionality after doing so. If your ready to upgrade, I think this is the best option. An updated version of OpenSSL is already included in the FreeBSD base, which requires no workarounds for Home Assistant. Other issue that are appearing in the 11.3-RELEASE, simply do not exist.
I’ve started a wiki page to help get your existing plugin working again on TrueNAS Core
I recently upgraded to TrueNAS and have upgrade all my jails except homeassistant. I am having an odd problem running the upgrade on my 11.3 plugin. I have successfully upgraded other plugins with this approach, but I’m not sure how to proceed here. Any thoughts would be appreciated.
The homeassistant.json file exists and is readable in the iocage/jails/homeassistant directory. There are no errors that I can see in it’s formation… Odd
Error:
# iocage upgrade homeassistant
Snapshotting homeassistant...
Snapshot already exists
Updating plugin INDEX...
A plugin manifest matching homeassistant could not be found!
I have been using it for quite a few days now, maybe like a month?
And its pretty good, I actually like having Node-red separated from HASSIO in case anything happens to the HASSIO install…
does anybody else seem to have a “slow” performance when loading entities history? Mine is taking a few seconds to load and show the graphs, when it was done instantly on my old Managed HASSIO Install
Hi @davids777 - This is an odd error indeed – I think I’ve seen this happen before with others as well. I can’t remember exactly how ATM but I’m pretty sure I was able to get it resolved.
Any chance this is a simple oversight? Please use the next command to list your jails and confirm the name your $_JAIL_NAME is in fact named homeassistant
iocage list
Have you tried to REFRESH INDEX (be sure to select community from the drop down menu first)
Attention FreeNAS users – The FreeBSD 11.3-RELEASE is now past it’s EOL date .