No harm in giving it a try, but I personally wouldn’t bother with a selfhosted solution for it. Especially if you’re not sure it will work out.

Well, paint me green and call me a pickle. More power to you if it works. 😊

Tangent, unsolicited:

Music lessons over video call, that has to be a real pain. I can’t find it now, but there’s an Adam Neely video where he talks about why online recording sessions can’t work, as transmission latency works against the immediacy needed to play music together. He said it better than I can.

Except if your idea is to play in turns, but then capturing the thing you want to show… Can’t you find another teacher closer to you?

Installing the Jellyfin add on into kodi takes a few minutes. Nothing much to consider, just try it and see if that changes anything.

I have a similar setup (rpi with OSMC, media hosted on file server) and prefer using Jellyfin as the source for all clients, as it keeps track of watched status across everything. It’s not perfect, but better than without Jellyfin.

According to Varoufakis, Europe missed the bus on cloud capital (=big cloud platforms like amazon, meta, twitter,…) and the race is currently playing out between US and China.

Terrible opsec sharing your WiFi SSID, by the way. I can’t find one right now, but I’ve seen global “wardriving” maps of all broadcast WiFi SSIDs that allow to pinpoint a somewhat unique SSID or at least narrow down to a few options. A list of SSIDs around you pretty much gives away your precise location.

Had similar behaviour last night. Turned out UnboundDNS had crashed in my opnsense firewall and took “internet connectivity” with it. Restarting the service fixed it in one click after I found it.

It’s not my Github, but I think you’d do something like print and store in a safe place your trusted party has access to. My SO has my Keepass password stored in their password safe and theoretically knows (and hopefully will recall when the need arises) how to find my Keepass file, for example.

In short, it’s trust. And then there’s the fact that they would never voluntarily touch this stuff anyway. 😅

Not about design patterns, but about making preparations: https://github.com/potatoqualitee/eol-dr

Storage box is self-serviced storage on a single server, as far as I’m aware. If you need replication, you need to rent storage at a second location and do it yourself.

I have a Raspberry Pi 3 with a Hifiberry DAC running OSMC (nicely packaged Kodi on top of Debian) acting as my media center and recently installed Jellycon with the hopes of being able to use server side transcoding for a few formats my old TV doesn’t support.

My verdict: Menu navigation is slow, but it’s a native kodi integration (supports widgets) and playback works great once you made your way through the menus. You can selectively set transcoding options per file type which is exactly what I needed.

Best solution I’ve seen so far, as it also does IR remote passthrough over HDMI if your TV supports it. The addon works in any kodi setup of course. I think there might be a way to start playback from the Jellyfin web UI but haven’t bothered with it. This would fully remedy the menu slowness, I think.

The answer seems to always be “not segmented enough”. ;)

Haha, why do I even ask.

This is a good hint, I’m going to take a look at that. Thank you!

I never specified, I think, and probably wasn’t too clear on it myself. Thanks for your insights, I’ll try to take them to my configuration now.

This is exactly the type of answer I was looking for. Thanks a bunch.

So but in that way, having a proxy on the LAN that knows about internal services, and another proxy that is exposed publicly but is only aware of public services does help by reducing firewall rule complexity. Would you say that statement is correct?

Right, I agree with proxy exploit means compromised either way. Thanks for your reply.

I am trying to prevent the case where internal services that I don’t otherwise have a need to lock down very thoroughly might get publicly exposed. I take it it’s an odd question?

Re “bouncer”: Expose some services publicly, not others, discriminated by host with public dns (service1.example.com) or internal dns (service2.home.example.com), is what I think I meant by it. Hence my question about one proxy for internal and one public, or one that does both.

Right, I could have been more precise. I’m talking about security risk, not resilience or uptime.

“It’ll probably be the most secure component in your stack.” That is a fair point.

So, one port-forward to the proxy, and the proxy reaching into both VLANs as required, is what you’re saying. Thanks for the help!

The services run on a separate box; yet to be decided on which VLAN I put it. I was not planning to have it in the DMZ but to create ingress firewall rules from the DMZ.

One proxy with two NICs downstream? Does that solve the “single point of failure” risk or am I being overly cautious?

Plus, the internal and external services are running on the same box. Is that where my real problem lies?