If you have Ethernet cables that are old or have damaged ends in your pile just sacrifice them to make your own cable ties. Cut it into pieces as long as you need to wrap your other cables and in each section you cut you get four twist ties.
Cheap, readily at hand, and if the cables were bad you can call it recycling.
If you are just using a self signed server certificate anyone can connect to your services. Many browsers/applications will fail to connect or give a warning but it can be easily bypassed.
Unless you are talking about mutual TLS authentication (aka mTLS or two way ssl). With mutual TLS in addition to the server key+cert you also have a client key+cert for your client. And you setup your web server/reverse proxy to only allow connections from clients that can prove they have that client key.
So in the context of this thread mTLS is a great way to protect your externally exposed services. Mutual TLS should be just as strong of a protection as a VPN, and in fact many VPNs use mutual TLS to authenticate clients (i.e. if you have an OpenVPN file with certs in it instead of a pre-shared key). So they are doing the exact same thing. Why not skip all of the extra VPN steps and setup mTLS directly to your services.
mTLS prevents any web requests from getting through before the client has authenticated, but it can be a little complicated to setup. In reality basic auth at the reverse proxy and a sufficiently strong password is just as good, and is much easier to setup/use.
Here are a couple of relevant links for nginx. Traefik and many other reverse proxies can do the same.
The biggest question is, are you looking for Dolby Vision support?
There is no open source implementation for Dolby Vision or HDR10+ so if you want to use those formats you are limited to Android/Apple/Amazon streaming boxes.
If you want to avoid the ads from those devices apart from side loading apks to replace home screens or something the only way to get Dolby Vision with Kodi/standard Linux is to buy a CoreELEC supported streaming device and flashing it with CoreELEC.
List of supported devices here
CoreELEC is Kodi based so it limits your player choice, but there are plugins for Plex/Jellyfin if you want to pull from those as back ends.
Personally it is a lot easier to just grab the latest gen Onn 4k Pro from Walmart for $50 and deal with the Google TV ads (never leave my streaming app anyways). Only downside with the Onn is lack of Dolby TrueHD/DTS Master audio output, but it handles AV1, and more Dolby Vision profiles than the Shield does at a much cheaper price. It also handles HDR10+ which the Shield doesn't but that for at isn't nearly as common and many of the big TV brands don't support it anyways.
I've got about 30 zwave devices, and at first the idea of the 900mhz mesh network sounded like a really solid solution. After running them for a few years now if I were doing it again I would go with wifi devices instead.
I can see some advantages to the mesh in a house lacking wifi coverage. However I would guess most people implementing zigbee/zwave probably have a pretty robust wifi setup. But if your phone doesn't have great signal across the entire house a lightswitch inside of a metal box in the wall is going to be worse.
Zwave is rather slow because it is designed for reliability not speed. Not that it needs to be fast but when rebooting the controller it can take a while for all of the devices to be discovered, and if a device goes missing things break down quickly, and the entire network becomes unresponsive even if there is another path in the mesh. Nothing worse than hitting one of your automations and everything hangs leaving you in the dark because one outlet three rooms over is acting up.
It does have some advantages, like devices can be tied to each other (i.e. a switch tied to a light) and they will work even without your hub being up and running (zwave controller I think can even be down).
Zwave/Zigbee also guarantee some level of compatibility/standardization. A lightswitch is a lightswitch it doesn't matter which brand you get.
On the security front Zwave has encryption options but it slows down the network considerably. Instead of just sending out a message into the network it has to negotiate the encrypted connection each time it wants to send a message with a couple of back and forth packets. You can turn it on per device and because of the drawbacks the recommendation tends to be, to only encrypt important things like locks and door controls which isn't great for security.
For Zwave 900mhz is an advantage (sometimes). 900mhz can be pretty busy in densely populated areas, but so can 2.4 for zigbee/wifi. If you have an older house with metal boxes for switches/plaster walls the mesh and the 900mhz penetration range may be an advantage.
In reality though I couldn't bridge reliably to my garage about thirty feet away, and doing so made me hit the Zwaves four hop limit so I couldn't use that bridge to connect any additional devices further out. With wifi devices connecting back to the house with a wifi bridge, a buried Ethernet cable, etc can extend the network much more reliably. I haven't tried any of the latest gens of Zwave devices which are supposed to have higher range.
The main problem with wifi devices is that they are often tied to the cloud, but a good number of them can be controlled over just your LAN though. Each brand tends to have their own APIs/protocols though so you need to verify compatibility with your smart hub before investing.
So if you go the wifi route make sure your devices are compatible and specifically check that your devices can be controlled without a cloud connection. Especially good to look for devices like Shelly that allow flashing of your own firmware or have standardized connection methods in their own firmware (Shelly supports MQTT out of the box)
Yeah like I said it only works if they don't look too deep.
My assumption would be that they aren't going to bother to go to court if they can't see any public records (vehicle registration, titles, etc) without liens that they would be able to get money out of.
So if they don't bother to check who the lien holder is they will likely just move on to the next person to squeeze money out of.
And yeah if they do go to court the scheme will quickly fail, but the whole reason these people think their magic incantations work is because the courts/creditors/etc often just ignore them because it ends up costing more to fight them than to properly enforce the law/contracts.
If you owe money they can still sue you and the court can force you to turn over assets.
There are some protections around the court taking away your primary residence, but I don't think there is anything stopping them from taking away automobiles (likely varies state to state).
So I wasn't talking about the original lein holder repossessing th vehicle, but instead other creditors that now see assets that are open on the books and seeking legal action to get their money back. Unlikely they will want to pay lawyers to do that for your car, but still possible.
Presumably saying that if the loan is discharged that means there is no longer a lien on it. Putting one on it yourself (if that is possible?) might prevent creditors from using the courts to repossess it to get their money back. In reality the best it might do is to make them think it isn't an asset they can come after you for if they don't look close enough at the lien holder.
I am not a SAN admin but work closely with them. So take this with a grain of salt.
Best practice is always going to be to split things into as many failure domains as possible. The main argument being how would you test upgrades to the switch firmware without potentially affecting production.
But my personal experience says that assuming you have a typical A/B fabric that is probably enough to handle those sorts of problems, especially if you have director class switches where you have another supervisor to fail back to.
I've personally seen shared dev/prod switches for reasonably large companies (several switches with ~150 ports lit on each switch), and there were never any issues.
If you want to keep a little separation between dev and prod keep those on different VSANs which will force you to keep the zones separated.
Depending on how strict change management is for your org keep in mind that tangling dev+prod might make your life worse in other ways. i.e. you can probably do switch firmware updates/zoning changes/troubleshooting in dev during work hours but as soon as you connect those environments together you may have to do all of that on nights and weekends.
Like most have said it is best to stay away from ZFS deduplication. Especially if your data set is media the chances of an entire ZFS block being the same as any other is small unless you somehow have multiple copies of the same content.
Imagine two mp3s with the exact same music content but with slightly different artist metadata. A single bit longer or shorter at the beginning of the file and even if the file spans multiple blocks ZFS won't be able to duplicate a single byte. A single bit offsetting the rest of the file just a little is enough to throw off the block checksums across every block in the file.
To contrast with ZFS, enterprise backup/NAS appliances with deduplication usually do a lot more than block level checks. They usually check for data with sliding window sizes/offsets to find more duplicate data.
There are still some use cases where ZFS can help. Like if you were doing multiple full backups of VMs. A VM image has a fixed size so the offset issue above isn't an issue, but if beware that enabling deduplication for even a single ZFS filesystem affects the entire pool, even ZFS filesystems that have deduplication disabed. The deduplication table is global for the pool and once you have turned it on you really can't get rid of it. If you get into a situation where you don't have enough memory to keep the deduplication table in memory ZFS will grind to a halt and the only way to completely remove deduplication is to copy all of your data to a new ZFS pool.
If you think this feature would still be useful for you, you might want to wait for 2.3 to release (which isn't too far off) for the new fast dedup feature which fixes or at least prevents a lot of the major issues with ZFS dedup
More info on the fast dedup feature here https://github.com/openzfs/zfs/discussions/15896
Third party solutions can at least partially fix this. I have this site: https://spotifyshuffler.com/ create a shuffled copy of my playlists occasionally. Then you just play the pre-shuffled playlist with shuffle disabled.
In my case I have a large (several thousand track) playlist, and I turn on Spotify's shuffle just to pick the first track at a somewhat random spot in the large list and then shut their shuffle off toward continue the pre-shuffled list without their manipulation. Whenever I add content to the playlist I have it reshuffled.
Contrary to a lot of posts that I have seen, I would say ZFS isn't pointless with a single drive. Even if you can't repair corruption with a single drive knowing something is corrupt in the first place is even more important (you have backups to restore it from right?).
And a ZFS still has a lot of features that are useful regardless. Like snapshots, compression, reflinks, send/receive, and COW means no concerns about data loss during a crash.
BTRFS can do all of this too and I believe it is better about low memory systems but since you have ZFS on your NAS you unlock a lot of possibilities keeping them the same.
I.e. say you keep your T110ii running with ZFS you can use tools like syncoid to periodically push snapshots from the Optiplex to your T110.
That way your Optiplex can be a workhorse, and your NAS can keep the backup+periodic snapshots of the important data.
I don't have any experience with TrueNAS in particular but it looks like syncoid works with it. You might need to make sure that pool versions/flags are the same for sending/receive to work.
Alternatively keep that data on an NFS mount. The SSD in the Optiplex would just be for the base OS and wouldn't have any data that can't be thrown away. The disadvantage here being your Optiplex now relies on a lot more to keep running (networking + nas must be online all the time).
If you need HA for the VMs you likely need distributed storage for the VMs to run on. No point in building an HA VM solution if it just moves the single point of failure to your NAS.
Personally I like Harvester, but the minimum requirements are probably beyond what your hardware can handle.
Since you are already on TrueNAS Scale have you looked at using TrueNAS Scale on the Optiplex with replication tasks for backups?
If your NAS has enough resources the happy(ish) medium is to use your NAS as a hypervisor. The NAS can be on the bare hardware or its own VM, and the containers can have their own VMs as needed.
Then you don't have to take down your NAS when you need to reboot your container's VMs, and you get a little extra security separation between any externally facing services and any potentially sensitive data on the NAS.
Lots of performance trade offs there, but I tend to want to keep my NAS on more stable OS versions, and then the other workloads can be more bleeding edge/experimental as needed. It is a good mix if you have the resources, and having a hypervisor to test VMs is always useful.