I recently got interested in trying out iSCSI, since I had spare capacity on my server. For those unaware, iSCSI can expose block devices over a network. Instead of a file system, it exposes a (virtual) disk, and lets the system connecting to it manage high-level details, including its own file system. This has very different trade-offs from file sharing like SMB/NFS; sharing the disk isn’t really possible, but you avoid a lot of the performance impact from (often different) file system semantics.
This makes it possible to do things you might otherwise not recommended with file sharing, like hosting a Steam library on it. Especially so if you have the iSCSI setup on its own network. Remember, most file systems assume a mostly direct connection to disk. Running this over a shared Ethernet connection, let alone WiFi might not be the best idea.
Also note that I’m not describing a secure setup here. This is very much “baby’s first”, and should only be done on a secure network, or as an experiment. Securing it will involve properly configuring things like portal groups, and isn’t covered in this article. I might cover it in a later article.
This also synthesizes a lot of information I found online; in particular, this basically digests some information in the FreeBSD handbook about the iSCSI target subsystem and ZFS volumes, plus Red Hat and Oracle documentation on
I had recently upgraded my NAS from FreeBSD 13.0 to FreeBSD 13.1. Unfortunately, I found out that the Deluge package was faulting on startup. It turns out that when FreeBSD updated the
libtorrent-rasterbar package, it had broken the Python bindings, and thus Deluge. However, the old Deluge and Python binding package were still installed – they just didn’t work anymore due to
While it’d be ideal if this were fixed upstream, I didn’t have the patience for this right now. So, I decided to downgrade the
libtorrent-rasterbar package to be compatible with the Python bindings. There were no other dependent packages, so I figured this was safe. Unfortunately, I had to deal with a few curveballs along the way…
I needed to set up a daemon for a service that’s in the low 1024 ports reserved for root on FreeBSD. However, I didn’t want to run the service as root. Instead, I set up pf (the firewall in BSDs) to simply redirect the port.
A quick post since this isn’t well covered: FreeBSD on EFI systems still will hard-code the name enumerated at install time (like
da0p2). There is a better way than using
glabel (which injects itself into the last block of the partition, which can be problematic). Instead, you can use GPT labels, which are cross-platform and well-known.
I had recently gotten such a NAS for dirt cheap (they didn’t know what they had!), and wanted to put it into useful service. The specifications include a Celeron J1800, and mine had been upgraded to 8 GB of RAM in its past life.
The OS on these things (QTS) is bizarre; basically a homelab in a box, but it’s sludge. The UI is some fake desktop thing, in the vein of eyeOS/YouOS of old. There are servers for things like LDAP, MariaDB (recommending you use phpMyAdmin…) and RADIUS, but I’m not sure who would even use them. There’s even an X server running, for some reason – with IR remote support! This thing is really a low-end SMB-for-SMB and Plex box through and through. I didn’t really like the OS though, so I decided to load something else on.