Let’s look at the recent case where the FBI/Google took down a sites related to a botnet that was using Android TV boxes that came equipped with malware. These were cheapo, third tier units probably sold via Temu or some equivalent.

In this case they were being used to relay and obfuscate crime related traffic, but there’s no reason that the same technique couldn’t be used to more directly attack the hosting network.

I think that if you assume that device that you plug into your network could be used as an edge router into your network for a WireGuard connection with the outside world, then isolating those devices from your homelab is a good idea.

Something like an Android TV box obviously needs to connect to the Internet, and there are good reasons that you might want to run a VPN on it too. So trying to limit its access to the Internet via ports would be difficult. A VLAN would give me some piece of mind here.

Remember that separation by VLANs does very little unless you have firewall rules that limit traffic between them.

When I started out, I really wanted to do it this way too. A bare metal install just seemed a little crude, and I thought I might want to run other firewall related services from that node. I had technical issues, and OPNSense just didn’t want to run under Proxmox for me.

Finally, I said to hell with it and went with a bare metal install and, in retrospect, I’m glad it worked out that way.

OPNSense just works, and I don’t feel like there are any opportunities lost due to the bare metal install. Instead, it just feels really clean and sequestered from the homelab cluster as it should be.

I totally get the desire to want to muck about with Proxmox hosting and learn about how it works. That’s the right attitude. But hosting an OPNSense virtual machine isn’t the right starting place.

As a beginner, do beginner stuff. Install a Technitium container and learn about DNS. Install Immich, or Jellyfin or an *arr stack. But not a firewall as a VM.

Yeah, there is a line of units that has a PCI slot that then requires a riser card in order to be able to use it. The problem is that those units, from what I’ve seen, tend to cost at least twice as much as the M910Q/M710Q. Even the M920Q/M720Q are significantly more expensive. Not to mention, a bit more difficult to get hold of.

IMHO, once you’re talking about dropping $300-$350 on one of these models with the riser card, you really have to think hard about whether it’s worth it for 6th/7th generation Core i5 processors. Especially if you’re looking at a cluster of three. It seems highly probable that you could get something with an 11th/12th generation processor and multiple or 2.5GB ethernet ports for only a bit more, and you’d end up only needing two of them instead of three, and price might end up being a wash.

I am really, really curious to see how external USB 2.5GB or 5GB adapters would work. I’m getting the impression that they are a lot more reliable than they were even a few years ago, and might be a viable, cheap option.

All that being said, network speed hasn’t been an issue for me so far, and I’m not convinced that CEPH + HA, is a path I should be going down. Or a path that’s worth it for most self-hosters.

So far, the only thing that I’ve encountered that pushes the CPU on an ongoing basis is Frigate, and even that is performing well and not affecting other containers on the same host. But I’m still adding services to my cluster, so who knows.

I watched a whole bunch of videos about those and it totally looks like they would work electronically. But most of them wouldn’t fit in any of the ports on the back without modification and 3D printing magic. Some people left them “just hanging out”.

I’ve got the article just about ready to go. I got myself swallowed up in a project to implement Frigate (finally) and just didn’t get around to posting it. It should be up tomorrow.

Yes, I saw that comment. I wasn’t sure what “But… it has so many downsides…” meant, and the comment doesn’t clarify.

To me, the big question is how the “improvements” they are going to make would my installation better. I suspect that most of the improvements are ones that allow them to make Music Assistant better, or allow them to add tighter integration with Music Assistant.

As far as I know, they haven’t rolled it out yet. But that thread is almost a year old now.

I would be interested to see what they’ve done.

That reference is in one of the programming articles. You must have poked around a bit to find it. “Set it and forget it!”.

It was in my list of options when I started. I liked the modularity of SnapCast, though. SnapCast just handles the whole-home aspect, and the you pair it with a music player that you like.

Not specifically, but SnapCast will accept a range of input methods and should be capable of taking output from virtually anything that plays sound.

This was a little problematic at first. Part of my shift over to OPNSense was that I bricked my mesh WiFi when attempting to put it into AP mode. So I had to scramble around to get a WiFi AP. Initially it was upstairs and connected to a swtich that was connected to the homelab in the basement through a Powerline AV. The Pi0’s dropped out a lot.

My house is too old for Cat5 in the walls, but does have some coax for cable TV. So I got some MoCa adapters and a second WiFi AP and sorted the WiFi out. After that, no WiFi problems with the streaming. I think the Powerline AV was just too unstable for the SnapCast.

There still are some occasional brief outages, and from what I can see this is caused by buffer overflows or something of that ilk with the SnapCast client software. I’ve adjusted the parameters as much as I can, and it seems pretty stable. I’ll notice a 1 or 2 second outage somewhere in the house every day or so.

Last week the SnapCast in the bathroom was glitching a lot, so I rebooted it and it’s been stable ever since. The one in the front room, which is literally 6" from the WiFi AP has never glitched at all, and it’s been running for about 3 months now.

I have a section in one of the articles where I talk about recovering from glitches that halt the Mopidy stream itself. In those cases, the Mopidy service is still running, but stops streaming. Using the REST API you can get it running again, so I wrote a cron job that checks every 3 minutes and restarts the stream if required.

I just came back from a 3 week vacation and after 2 weeks the Mopidy service itself crashed. I was getting Gotify notifications every 3 minutes from that cron job as it attempted to restart the stream. If since modified the Mopidy service to restart if it crashes, but it could be months before that ever happens.

I’ll wait to see.

Apparently you can run SnapCast on an ESP32 also. For me, the Pi0’s cost about $20 CDN, and the DAC card about the same, and the delivery from PiShop.ca was about 3 days. ESP32 would have cost less, but then require some kind of housing because of the two components flopping around. The Pi DAC’s slip onto the GPIO pins and the pair are essentially 1 thing at that point. Mine are just tucked away behind whatever the amps are.

I point out in Part II or III that these are essentially appliances once they’re set up. As long as they do the job, I don’t expect to upgrading them on a regular basis or anything like that. SendSpin looks cool because it does other stuff besides just stream music, but I’m not looking for that. From what I can see, SendSpin runs on Pi’s too, so it should be fairly simple to add that to the Pi0’s in the future if that’s what I want.

COBOL system written 50 years ago…JS package at release.

Depending on what you are doing with them, the drives can work just fine running through the USB ports, which can be faster than hard drives in most cases. I have my content - which is like 90% of the data space - on USB hard drives and the databases to manage them on the internal M.2 drive. Works fine for something like Immich.

I’ve seen people mention this a few times, but I’m not so sure that it’s actually a thing.

Switches are designed to route traffic intelligently, and they don’t blast all of the traffic to every port. If I remember correctly, at some point they do some kind of mapping between IP address and MAC address, and they know which MAC addresses are attached to which ports, and they only route the traffic to the port that has the MAC address they are looking for. I don’t know how much local switches collude with each other to share information about connected devices or how many hops they may be able to look into.

In any event, no matter how wrong I am about that, if you’ve got a device on switch A that needs to send packets to a device on Switch K, then Switch A either has to know that the device is on Switch K and the path to get to Switch K or it has to send the packet to every switch that it is connected to. That doesn’t change with VLAN’s, if Switch A doesn’t have knowledge about every other switch on the network, and which VLAN’s they are configured for, then it will have to send the packet to every switch it is connected to.

Compose is great for Android because it’s so integrated with the ecosystem. For desktop applications, JavaFX - especially coupled with Kotlin - is a clear winner to me.

I should point out that I don’t use FXML or SceneBuilder, but code all of my layouts in Kotlin. Kotlin features like extension functions let you eliminate 90%+ of the JavaFX layout boilerplate.

Back to Compose. Both Compose and JavaFX are Reactive GUI environments, although many (most???) people don’t realize that about JavaFX. But both environments take opposite approaches to Reactive design.

Compose, as the name implies, uses what I call “compositional reactivity”. This means that the actual layout is totally static, but is recomposed, in whole or part, in response to changes to the data representation of state. That code will look at the various State elements each time it runs, and alter the layout according to their current values.

JavaFX uses “Reactive Layouts” (my term, again). JavaFX has a comprehensive, yet extensible, collection of Observable data types and another comprehensive, yet also extensible, collection of Bindings to allow you to connect them together in any way that you can think of.

Every configurable element of every screen Node in JavaFX is expressed via these Observable values, meaning that they can be bound in some fashion - in either direction - to elements in the State data structure.

The result is that it JavaFX the layout code is run exactly once. But this layout code not only performs the actual layout, it also creates the bindings to State. After that, the layout behaves dynamically all my itself.

In JavaFX, layout composition is actually quite expensive in terms of performance, and recomposition is to be avoided if possible - and it is virtually always possible. I have seen people bitch about JavaFX being “heavyweight” and raggy, and I can guarantee you that those people are just doing a lot of recomposition.

The biggest challenge to programming, and I say this with more years of experience than most people reading this have been alive, is in understanding the underlying paradigm that governs whatever language or toolkit they are using. Unfortunately, you unlikely to open up a book or webpage and see, “The underlying paradigm of this technology is…”.

That’s especially true of JavaFX. It takes a LOT of time to realize the Reactive nature of JavaFX by yourself. Consequently, I don’t think that JavaFX gets recognized as the desktop application powerhouse that it is. As someone who has mostly mastered it, I’m constantly amazed at how trivial it is to build truely complicated applications with JavaFX.

Do your smart switches talk to your HomeAssistant server???

Or does your HomeAssistant server talk to the devices?

It’s probably the latter, and in terms of network security the difference is huge. You can restrict your smart switches to their own, untrusted zone with no outgoing permissions and then give HomeAssistant access to them from its zone.

I would also argue that your personal devices and desktop computers are far more sensitive than your HomeAssistant server.

I’ll have a look at it. The whole site is Jekyll using a theme called “Minimal Mistakes”, so there’s two things for me to look at. I suspect it’s the theme, and I’ve customized it enough that it’s probably “broken” when it comes to updates.

Thanks for the feedback. I will make some changes to the article. IPv6 wasn’t even on my radar since I haven’t got around to using it myself yet.

As an example, I was setting up SnapCast on a Debian LXC. It is supposed to stream whatever goes into a named pipe in the /tmp directory. However, recent versions of Debian do NOT allow other processes to write to named pipes in /tmp.

It took just a little searching to find this out after quite a bit of fussing about changing permissions and sudoing to try to funnel random noise into this named pipe. After that, a bit of time to find the config files and change it to someplace that would work.

Setting up the RPi clients with a PirateAudio DAC and SnapCast client also took some fiddling. Once I had it figured out on the first one, I could use the history stack to follow the same steps on the second and third clients. None of this stuff was documented anywhere, even though I would think that a top use of an RPi Zero with that DAC would be for SnapCast.

The point is that it seems like every single service has these little undocumented quirks that you just have to figure out for yourself. I have 35 years of experience as an “IT Guy”, although mostly as a programmer. But I remember working HP-UX 9.0 systems, so I’ve been doing this for a while.

I really don’t know how people without a similar level of experience can even begin to cope.