𝒍𝒆𝒎𝒂𝒏𝒏

Wholeheartedly agree.

Even if Yuzu did an oopsie and pushed a patch for leaked Zelda before official release, targeting the vaguely related reverse engineering projects is a completely unwarranted overreaction.

Not to mention the rampant legal threats to video creators for literal nothingburgers 🤦‍♂️

They won’t be getting a single cent or recommendation from me 🏴‍☠️

First time hearing about Sudachi!

Something is wrong with the tagginator in this thread, seems to be creating dupe posts every 1 min?

@db0@lemmy.dbzer0.com

Yepp sorry - what I meant was bundling multiple different root domains, e.g. example.com & example1234567.org in the same cert.

I currently do as you mentioned above, renewing with just one root bundled with its accompanying subdomain wildcard.

If anyone is interested in mitigation, the only way around this AFAIK is to start with a brand new domain, only use wildcard certs (with DNS validation), and don’t bundle multiple renewals into a single cert.

Also, don’t enter your domain or related IP address into dns reverse engineering tools (like dnsdumpster), and check certificate transparency logs (https://crt.sh) to see what information related to your cert renewals has been published.

This won’t stop automated bots from scanning your ip for domains, but should significantly reduce the amount of bots that discover them

Curious about your reasoning, especially as I bought a .dev for myself a while back (via a different registrar)

If it was in regards to the .zip TLD then I guess that is understandable, but .dev seems harmless IMO

Not exactly IMO, as containers themselves can simultaneously access devices and filesystems from the host system natively (such as VAAPI devices used for hardware encoding & decoding) or even the docker socket to control the host system’s Docker daemon.

They also can launch directly into a program you specify, bypassing any kind of init system requirement.

OC’s suggestion of a chroot jail is the closest explanation I can think of too, if things were to be simplified

I wish we could do this, but against Nintendo’s billions we may struggle a lot.

Yuzu was making 30k/mo and their best option was to quit… we’d need an order of magnitude more supporters to even be able to consider this viable.

The closest thing we could maybe do is donating to the EFF, they’re best suited to defend stuff like this. They prevented the RIAA from trying to take down “youtube-dl” for example, an archival tool supporting videos from YouTube and many other sites. The RIAA also used many of the same arguments that Nintendo used against Yuzu

About 150w total, trying to bring it down since electricity here is pretty expensive.

4 machines: two 4th gen i5, one 6th gen Nuc (Have two more but not set them up yet), and one HP thin client. Also two UPSes, and 3 cameras (previously four, but one was accidentally damaged).

Hosting Home Assistant, Zabbix, Palworld, SMB, Transmission, Plex and a bunch of other misc stuff.

Kind of contemplating moving everything to a 10th gen Nuc, but thinking a Ryzen based mini pc might be a better option

Please don’t self-host DNS. It can be exploited and abused in many ways if you don’t know what you’re doing.

Seconded

One of these is DNS reflection, a type of amplification DDoS I found out about several years ago… You send a tiny packet to a DNS server requesting a domain with long records, but tell the DNS server to send the response to another address. Pretty interesting and amusing imo, but probably not if you’re on the receiving end of one lol

I went with the virtual appliance when I installed Home Assistant several years ago, turned out to be a great decision looking at how it’s architected. I only self-host the database separately, which i’ve found easier to manage.

the fact that the storage usage keeps growing

There should be a setting to reduce how long Home Assistant retains data for - I removed the limit on mine, however its possible that on newer versions they’ve changed the default

Hope you find a solution though - I think node red (capable of doing dashboards on its own) with something else is going to get you part way there.

I used to pass all the data through to Home Assistant and show it on some dashboards, but I decided to move over to Zabbix.

Works well but is quite full-featured, maybe moreso than necessary for a self hoster. Made a mediatype integration for my announciator system so I hear issues happening with the servers, as well as updates on things, so I don’t really need to check manually. Also a custom SMART template that populates the disk’s physical location/bay (as the built in one only reports SMART data).

It’s notified me of a few hardware issues that would have gone unnoticed on my previous system, and helped with diagnosing others. A lot of the sensors may seem useless, but trust me, once they flag up you should 100% check on your hardware. Hard drives losing power during high activity because of loose connections, and a CPU fan failure to name two.

It has a really high learning curve though so not sure how much I can recommend it over something like Grafana+Prometheus - something I haven’t used but the combo looks equally as comprehensive as long as you check your dashboard regularly.

Just wish there were more android apps

I run Plex too, and indeed library sharing is built right in and ridiculously easy to set up.

I think OP is already doing things the best way possible in Jellyfin by mounting others’ servers remotely over VPN

That’s halfway correct - I’ll try and break it down a bit further into the various parts.

Your subdomains are managed in using DNS - if you want to create or change a subdomain, that happens here. For each of your services, you’ll create a type of DNS entry called an “A record”, containing your service’s full domain name, and the IP address of your reverse proxy (in this example, it is 10.0.0.1)

The DNS records would look like the following:

• plex.example.com, 10.0.0.1
• octoprint.example.com, 10.0.0.1
• transmission.example.com, 10.0.0.1

With these records created, typing any of these domains in a browser on your network will connect to your reverse proxy on port 80 (assuming we are not using HTTPS here). Your reverse proxy now needs to be set up to know how to respond to these requests coming in to the same port.

In the reverse proxy config, we tell it where the services are running and what port they’re running on:

• plex.example.com is at server.example.com:32400
• octoprint.example.com is at server.example.com:8000
• transmission.example.com is at server.example.com:8888

Now when you type the domain names in the browser, your browser looks in DNS for the “A record” we created, and using the IP in that record it will then connect to the reverse proxy 10.0.0.1 at port 80. The reverse proxy looks at the domain name, and then connects you on to that service.

What we’ve done here is taken all 3 of those web-based services, and put them onto a the same port, 80, using the reverse proxy. As long as the reverse proxy sees a domain name it recognises from its config, it will know what service you want.

One thing to note though, reverse proxies only work with web-based services

A reverse proxy takes all your web-based services, e.g.

• plex on port 32400
• octoprint on port 8000
• transmission on port 8888

and allows you to map these to domain names, so instead of typing server.example.com:32400 you can type plex.example.com. I have simplified this quite a bit though - you need DNS configured as well, and depending on your requirements you may want to purchase a domain name if you intend on accessing content from outside your home without a self hosted VPN.

Cloudflare is a DDoS mitigation service, a caching web proxy, and a DNS nameserver. Most users here would probably be using it for Dynamic DNS. You can use it in combination with a reverse proxy as a means to mask your home IP address from people connecting to your self hosted web-based services remotely, but on its own it cannot be used as a reverse proxy (at least easily - would not recommend attempting to). Do note that Cloudflare can see all the data you transmit through their systems, something to bare in mind if you are privacy conscious.

In my opinion though, it would be much better for you to use a self hosted VPN to access your self hosted services (can be used in combination with the reverse proxy), unless there is a specific need to expose the services out to the internet

Edit: fix minor typo, add extra info about cloudflare

When your domain is close to running out, you should either get an email from your registrar asking you to renew, or a payment notification telling you that your domain will be renewed for whatever price automatically.

If the payment fails, the domain will be temporarily suspended. There is a grace period where nobody can buy that domain, allowing you to settle the missed payment. If you do not settle the payment, the domain will be put back up for sale

None of this affects whatever services you’re running on your Pi, people just won’t be able to connect to it if your domain is suspended.

I’d suggest looking into SSL certificates (Letsencrypt is free) as well as Cloudflare for masking your Pi (your home) IP address from users of your instance - do note this has privacy implications: cloudflare becomes a MITM for your site

Freenom is being sued by Meta (Facebook) at the moment for supposedly not dealing with spam domains. I would not recommend using a Freenom domain if/when they reopen registrations: FMHY had their old Freenom lemmy instance domain seized by Mali’s government

Mine’s pretty moderate in comparison to yours lol

• 2 cloud VPSes
• 2 physical locations
• 4 physical servers
• ~20-30 docker containers across the servers
• 3 VMs
• 3 managed switches
• 5 VLANs (2 with internet access)
• 2 SSIDs