fonix232

A docker container’s IP usage heavily (entirely) depends on how the container’s networking is defined by the host machine. And in an overwhelming amount of cases, that host networking will be a “here’s a device-local subnet your containers can join to”, so no, a Docker container won’t by default “get it’s own IP address” (colloquially, “its own IP address” would refer to a device getting a LAN-local address assigned to it from the local gateway/DHCP server), at least not one other devices on the network can access.

Also claiming that “nothing else will use port 80” is a gross over-simplification.

The move to port 80/443 on HAOS makes sense as it simplifies setup for total beginners.

Nah, it worked pretty well. Streaming was just more convenient, and came too soon after VOD became widely available.

VOD was a thing before streaming tho

No, that’s the evolution of venture capitalism.

Step 1: groundbreaking service comes in that fills a market hole

Step 2: people flock to service

Step 3: service gets VC funding to continue operations, subsidising the users

Step 4: service gets “copied”, competitors crop up, use VC funding to eke out their own marketshare while making things worse for everyone but themselves

Step 5: expansion plateaus as interest in service generalises (basically, everyone who could be interested, is already using it)

Step 6: VC funding depletes, company has to start making a profit - leading to price hikes, which is followed by other players in the market as that’s how capitalism works

Step 7: price hikes not being enough, service tries to capitalise on their userbase (think restricting features to a higher paid tier, introducing new tiers that strip away features, introducing ads, etc.)

Step 8: market is saturated with plateaud services, user movement is minimal, and everybody hates it because it’s expensive, and reintroduced the same problem the initial innovative service meant to fix.

Yep, that position is either kept open for a specific candidate (probably already working at the company), or it’s only there for legal requirements…

Thrussy? Put in.

“The best” depends on what you really need.

Authentik and Authelia are two of the top most quoted solutions, but they aim to be an “everything in one” package, with tons of features a simple homelab will rarely need. They’re aimed more at enterprise-like setups.

On the other end of the spectrum you have e.g. Pocket-ID, which only does OIDC by itself (you can hook up an LDAP server as user database though); but that tradeoff means it uses little to no CPU time, and, in my experience, around 130MB RAM. Given RAM is getting more expensive than gold, one needs to consider memory footprint, especially for older homelab setups. We can’t all be running 256GB nodes after all.

So instead of hunting the mythical “best” solution, decide what features you really need, grab a list of providers that cover those features, and compare them to see what fits your needs best.

The recommendations so far are quite solid.

I’d also add that crowdsec with the right collections as a primary filter within your reverse proxy setup can be extremely useful, potentially even better than fail2ban, as CS delivers a literal “scan every packet and put them against these rules” approach - where the rules are crowd sourced, thus are more up to date than any manual blocklists, filter list etc. can be, and can spot even 0day intrusion approaches.

It depends on the app. You can use Authentik as an OIDC provider and allow apps that offer OIDC to log in through that - and that usually works for TV sticks and such.

Uhm, no.

Only if the licence allows. I personally go for A/GPLv3 wherever I can because I don’t want corporations to just take and not contribute back. But that means I can’t just copy MIT/Apache software, need to do my own implementation from scratch. Which I prefer anyway.

why would I try a book REQUESTING system when I’m working on my own AIO solution?

I’m actually working on an all in one solution that sort of fills the roles of Readarr AND Calibre - without all the baggage of the latter.

Oh, and of course a KOReader library plugin that foregoes OPDS and works like the Kindle interface (“available books” synced from this backend, one tap downloads them, plus potentially adding series handling too in the future).

But right now it’s mostly manual downloads + CWA ingest + OPDS via KOReader.

An mSATA or small NVMe in a USB enclosure is the best way to go. No wasting a precious internal slot, and they can be super tiny (2230/2242 enclosures are dime a dozen).

You’re no fun

Windows Server exists.

It really shouldn’t, but it does.

Well it does stand for Node Packaged Malware soooo

Hub not required but a ZigBee adapter is.

You can buy ESP32 boards with built in DACs, just FYI.

Also there’s a handful of Pi Zero shaped ESP3 boards as well, which you could use with the existing DACs.

But again my point was that Sendspin requires even less hardware than Snapcast (and while technically you can indeed run Snapcast on an ESP32, last I checked it uses up a lot of resources, making the ESPHome given extras like BT proxy and usage in real time BT based location, unusable).

I am using it on a handful of devices (mainly voice interfaces), and it’s quite seamless, even in the beta stage.

Not up to Sonos level controls yet, but it’s getting there slowly. Music Assistant is gaining a lot of UX improvements recently, so it will be soon a viable alternative to not just SnapCast but Sonos too.

And you did it all in time just to have it be upended by SendSpin - which can even run on an ESP32 level MCU so you don’t even need a Pi Zero.