

Crossfading and normalization would both independently be dealbreakers for me. I can’t go back
Crossfading and normalization would both independently be dealbreakers for me. I can’t go back
I would be genuinely surprised if fair use draws the line on format-shifted, legally purchased media, at “remote watch-together”, leaving format-shifting and local watch-together in-tact.
If it were up to the studio’s interpretation of the law, you’d need to purchase a license for each person during local watch-together.
agree in principal, but in practice:
parents who live across the state
plexamp for music
I use ansible on one of my side projects; I use puppet at work. It’s the same reason I use raw docker and not rancher+rke2… it’s not about learning the abstractions; it’s about learning the fundamentals. If I wanted a simple abstraction I’d have deployed truenas and Linuxsserver containers instead of Taco Bell programming everything myself.
Sure. I have an r630 that is configured as an NFS server and a docker host called vacuum. There is a script called install_vacuum.sh that with a single command, can build the server to my spec from a base install of Ubuntu 24.04. it has functions to install base packages from repositories, add new repositories, set up users, create config files for NFS, smb, fstab, crontab, etc… once an NFS server exists on my network, any other server could be my docker host. My docker host is set up from a script install_containers.sh. as with before, it does all the things to get me a basic docker host, firewalled, and configured for persistence via my NFS server. It also has functions to create and start docker containers for all of my workflows (Plex, webserver, CA, etc), and if those containers don’t exist, it will build a docker image for said workflow based on a standardized format (you guessed it) bash build script for the containers. There is automation via cron on whatever host runs docker to build and update the containers once a week, bare-metal servers update themselves nightly, rebooting when necessary via unattended-upgrades.
Basically, you break everything down into the simplest function possible, have everything defined via variables in shared configurations that everything sources before running, and you have higher and higher level functions call other functions until you have a single function that cascades into a functioning system. Does that make sense?
Have you started collecting your notes into scripts?
Not sure if many people do what I do, but instead of taking notes I make commented functions in bash. My philosophy is: If I can’t automate it; I don’t understand it. After a while you build enough automation to build your workstations, your servers, all of your vms and containers, your workflows, etc, and can automate duplicating / redeploying them whenever required. One tarball and like 6 commands and I can build my entire home + homelab.
Nothing beats the bang/buck ratio of used enterprise hardware (always buy new drives though if you care about the data)
https://www.theserverstore.com/ https://www.serversupply.com/ https://www.servermonkey.com/
I’ve bought from all of these in the past, personally I’m a fan of dells but there are arguments for just about any of the major 3 (dell, hp, sueprmicro)
Personally my main server right now is an r630. 96 threads, 768gb of ram. With that many memory channels, not only can you run all of what you listed, you can even do medium-sized inferencing/diffusion if you’re interested in that sort of thing.
Fail2ban and containers can be tricky, because under the hood, you’ll often have container policies automatically inserting themselves above host policies in iptables. The docker documentation has a good write-up on how to solve it for their implementation
https://docs.docker.com/engine/network/packet-filtering-firewalls/
For your usecase specifically: If you’re using VMs only, you could run it within any VM that is exposing traffic, but for containers you’ll have to run fail2ban on the host itself. I’m not sure how LXC handles this, but I assume it’s probably similar to docker.
The simplest solution would be to just put something between your hypervisor and the Internet physically (a raspberry-pi-based firewall, etc)
You would expose a single port to multiple vlans, and then bind multiple addresses to that single physical connected interface. Each service would then bind itself to the appropriate address, rather than “*”
You should consider reversing the roles. There’s no reason your homelab cannot be the client, and have your vps be the server. Once the wireguard virtual network exists, network traffic doesn’t really care which was the client and which was the server. Saves you from opening a port to attackers on your home network.
Sorry I should have said “carbons and carbons related qol extensions”
Did you ever get carbons working properly? (As in, mobile and desktop clients of the same user both getting messages and marking as read remotely between them)
There are also full-suites like rancher which will abstract away a lot of the complexity
How has nobody in this thread said check_mk yet?
It’s free, you host it yourself. It’s built off of nagios, compatible with nagios plugins, supports snmp or agent based checks. It can email, SMS, slack or discord you when something breaks, you can write your own custom checks in any language that can output to a local console… I could never imagine even looking for something else.
has xmpp figured out carbons yet between multiple clients? also are there any good mobile clients?
If one doesn’t exist, it would seem to be a fairly straightforward (if not a smidge tedious) thing to implement. Ever thought about learning web development?
A raspberry pi or orange pi could definitely run all of those things at very low power consumption.
I have a little 4 core/ 8gb ram VM running my work instance that monitors over a thousand clients on 60s check intervals, you may want to look into your config. I honestly have no idea what could cause 15 machines to cost that much computationally
Thank you for letting me know what software not to use; good bot