Frigate isn’t a resource hog unless you enable the inference and classification stuff. If you don’t need that, and are only running 2 cameras, it should be fine.

Shinobi is another option without all the advanced junk you may not need though.

Read the first sentence at least, c’mon.

1. Okay, so no issues there
2. DHCP handles the address assignments in your network, not DNS. DNS resolves to named host queries. If no devices got IP addresses, that’s one problem. If you couldn’t resolve public hosts like www.news.com, that’s a DNS problem. If you couldn’t resolve INTERNAL named hosts you refer to around your network, then that’s also DNS, but a different problem.

My hunch here is that you MIGHT be using a named host as your DNS resolves instead of an IP address in your network, OR, for some reason your DNS resolves doesn’t have a static address. Never use named hosts to point to network services, and all network services need a static IP, so go and check all of that.

Well…no, and this is what I’m saying.

Every downstream issue you try to solve with redundancy has a doubled and duplicate cost to it’s upstream. Internet links, load balancers for web services, and in this specific situation, UPS’s.

Throwing more servers at a homelab with no power is just wasting money without more UPS power in the mix. You have 4 servers, and want HA for everything on your network, expect to have two of everything, including UPS units.

This is the n* sunken cost of redundancy at its core, and in your example, you’re assuming this person even had a generator or whatever, but even if they did, they’d need an even BIGGER generator to run all this stuff.

That’s why my points deal with solving for what they have and making it work better than, instead, immediately jumping to adding more and more and more to the stack. It’s just not necessary when all they want is a graceful recovery to power loss.

Need more details here:

1. What’s your bandwidth and delivery medium like?
2. What are your edge/router specs?
3. What hardware would you be hosting this on?
4. What format are you expecting to stream (audio and video formats)?
5. Related to #5, what hardware would you streaming from?

OBS and Owncast should allow you to do this for the most part, but it’s heavily dependent on all of the above.

There’s a lot of layers here, so let me work backwards from the edge, inward:

1. You lost power, so you probably lost internet if your endpoint hardware was not also on a UPS. Nothing is going to stop that unless you get a multi-WAN router, and an LTE backup on standby. Probably not worth the cost.

2. You shouldn’t have lost DNS or DHCP for your local network just because of a reboot. Something is wrong with your setup, and we’d need more info about said setup to say more, but generally these services are stateful for the most part, and shouldn’t lose state on reboot IF you have them configured properly for your local domains, like a DNS forwarded, and static reservations on DHCP for local devices.

3. You don’t need HA for all your services. You need to fix the issues with your services not running properly with interruptions. The specific services you mentioned don’t behave poorly of they die and come back in properly configured environments.

4. If you have a UPS in your home, all devices connected to UPS should be getting information about the status of said UPS and shutdown cleanly when thresholds are met. Install NUT somewhere, and upsmon on all your hosts to properly issue shutdown signals when you lose power, and the UPS starts discharging. The thresholds you set for this are up to you.

In general, you don’t need to overthink HA, you need to focus instead on your services recovering gracefully in these situations. Spending insane amounts of time and money to make highly available services for your media and home automation will only leave you having spent resources and realizing there is no way to ever get to 100% uptime without flaws somewhere.

Again, it’s nearly impossible to scrub the entire internet of the code to just run a single command and build a docker image of whatever you were running yourself. If you have the image locally, you can just push it anywhere you want.

Keep Dockerfile, keep checkouts of what you’re running, or push images locally. All very simple.

I mean…you have the container right there on your machine. If you’re concerned, just run your own registry and push copies there when needed. This of course is all unnecessary, as you only need the Dockerfile to build a clean image from scratch, and it will obviously work if it’s already been published.

LOVELY COMMENT.

What are you getting at?

So why don’t we just rename the group to “Puritan Self-Hosting Only”? Where is your line?

Stop giving the purists cred here.

If it works for you, use it. Christ.

Ain’t nobody gonna buy your stupid Nazibots either, di ckhead. You are universally despised.

The simplest and most pragmatic option.

#3

Interesting if true…

This again? 🙄

I did answer your questions, but if I missed something, feel free to ask and I can clarify.

The clients (apps) enforce key symmetry for your own keys, server identity, and the exchanged with the other person part of a conversation. Constantly. There is no way to MITM that.

The clients are open source, and audited regularly, and yes, builds are binary reproduceable and fingerprinted on release.

That’s not to say someone can’t build a malicious copy that does dumb stuff and put it in your phone to replace the other copy, but the server would catch and reject it if it’s fingerprints don’t match the previously known good copy, or a public version.

Now you’re just coming up with weird things to justify the paranoia. None of this has anything to do with Signal itself, which is as secure as it gets.

The closest you’re probably going to get to a half decent looking WYSIWYG editor is something templatized top to bottom. Odoo, Ghost…things like that.