Redundancy. I have two independent firewalls, each separately routing traffic out through two totally independent multi-homed network connections (one cable, one DSL, please god somebody give me fiber someday) that both firewalls have access to. For awhile was thinking of replacing the DSL with starlink until Elon turned out to be such a pile of nazi garbage, so for now DSL remains the backup link.

To make things as transparent as possible, the firewalls manage their IPs with CARP. Obviously there’s no way to have a single public IP that ports itself magically from one ISP to another, but on the LAN side it works great and on the WAN side it at least smooths out a lot of possible failure scenarios. Some useful discussions of this setup are here.

You’re absolutely incorrect about IRC. Would you like to learn? Open IRC federation is basically never used anymore and the few networks that exist are very stable (if not completely calcified), but it is a core feature of the design, and in the old days, massive interconnected networks of IRC servers like EFnet and Undernet spanned the globe, there were even some servers that allowed open federation (EFnet is actually named for it – eris-free-net referring to the last server “eris” that supported free federation), and at some points Netsplits were a frustratingly daily occurrence. Like with any federation, abuse is the reason we can’t really have nice things anymore, but IRC absolutely supports federation. Not very well from a modern standpoint since it didn’t really keep up with the abuse arms race, but when it was first conceived it was way ahead of its time.

IRC and XMPP are infinitely less painful, honestly, and both were designed around federation from the ground up, long before it was cool.

I’ve always felt like this is an area with a huge gap. I’ve got my own fragile, cobbled-together bullshit that works for me, but it’s far from ideal or reliable if I’m being honest. I do love Ansible’s general idea of relying on standard, always-ish available protocols like ssh as a universal connection method, and I think it could work well as the bulletproof lower layer when you want to use direct control over the CLI tools and configuration files, like what git provides for anything requiring version control, but ansible needs a slick management interface like github/forgejo provides on top of git, to fill in the higher level UI for when you need a wider scope to get an overview of what’s going on or to make general configuration changes without needing to get your hands dirty. Ideally it would look a lot like Proxmox itself does, just, not specific to Proxmox. Like if I want to add my Steam Deck, and I’ve got ssh enabled on it and it’s not asleep, it should be able to ansible its way in there somehow to at least get whatever basic details it can. Maybe that’s only basic system information at first, but from there I could work on customizing it. That’s what I would consider the ideal, for me at least.

Yes, all three are supported configurations. Technically all four, since “I don’t know” is apparently a completely valid and functional configuration too.

I’ll add a vote to all the people suggesting Yunohost. Yunohost is a perfect place to get your feet wet with basically no experience required. I’ve played with it myself and it does a good job of simplifying and holding your hand without oversimplifying or keeping you on a strict, tight leash. It even helps you deal with common newbie issues like dynamic IPs so you can become more reliably available on the internet, something that a lot of other guides just assume you’re going to have a static IP assigned by your ISP or VPS and handwave away the complexity of what you’ll have to do if you have a dynamic IP like most home connections. (Experienced self-hosters gradually discover that having access to a static IP somewhere, anywhere, makes life a lot easier, but don’t worry, you’ll get there too eventually, it’s not important when getting started)

You can get started by working your way through the process here.

I’d recommend using conductive filament if you can or even just coating it with conductive paint before it touches anything electrically sensitive might do the trick. It doesn’t have to be a great conductor, just a tiny bit of conductivity will prevent any significant static charges from building up.

Ugh, I hate it when tools to “simplify” an already relatively simple process actually oversimplify it to the point of making it horribly complex to work around their “simplification”. A few points I’d like to answer from your post:

• Nginx-Proxy-Manager is dumb for, as far as I can see, not allowing you to follow the standardized method of answering challenges that supports any DNS provider and instead only seems to allow its “magic simplified process” that only works with select DNS providers
• https://dns.he.net/ is a nice free DNS service that you could use for your “keep domain at bluehost but use DNS servers elsewhere” strategy, and this is a totally valid and reasonable configuration – however, it apparently won’t help with Nginx-Proxy-Manager due to above stupidity
• This leaves your only DNS hosting service option as Cloudflare, as you correctly identified. This is a fine option but you know what they say about free services especially when they’ve got big for-profit companies behind them, if you’re not paying for the product, then you ARE the product, so beware of becoming vendor-locked and enshittified when they inevitably decide to try to monetize you somehow (if they’re not already doing so behind the scenes).
• Yes you can transfer your domain to a supported provider. This is kind of a “nuclear option” to get it to work with some shitty web-UI like Nginx-Proxy-Manager just because they’re too lazy to support actual standards or play nice with manual configurations, but it’s straightforward, albeit a little bit slow process (can take several days for things to switch over)
• There is no “renewal cost” for transferring a domain other than having to pay for 1 year minimum of the new provider’s normal annual registration costs. This gets added to your existing expiry, generally speaking, or your old time gets refunded, so either way you’re not losing anything, however things can get complex if you’ve only recently registered or renewed it, for example

If you’re very happy with Bluehost and want to stay there (I have no idea if they’re any good I’m not familiar with them but I will say charging $90 for an SSL certificate seems a bit absurd) then Cloudflare is probably the path of least resistance.

If you don’t mind transferring your domain and waiting for that process, that’s also a good approach.

But personally, I would drop Nginx-Proxy-Manager like a hot potato and work your way through setting up something like Caddy instead, doing mostly the same magic that NPM does (unfortunate acronym for anyone who’s more familiar with Node Package Manager) but using a very open and flexible system, supporting plugins for different providers to support DNS challenges for example

One final option that I’m going to throw out there, is if you intend on connecting your web server to the public internet anyway, and you’re able to live without a wildcard DNS (this just means it has to create a different certificate for each subdomain you add, not a big deal when a program is already managing them for you in my opinion) then you can just forget about the DNS challenge altogether and use a regular HTTP challenge. Again, fully standards compliant. Doesn’t matter what DNS or web server you’re using. As long as it has an internet connection so it can talk to the encryption certificate server and verify that it is who it says it is, you’re good to go, no need for DNS keys and such. Frankly I find the HTTP method just as simple if not simpler in most cases. Again, they’re oversimplifying to the point of making it more complex.

I have installed sunshine and moonlight on every computer I own and I use it so often I barely remember what computer I’m actually on anymore.

Nah, we should strive for it. Imagine how much time I’d have for things like actually touching grass and socializing with real humans if I used an AI to handle all my terminally online activities. It can provide me a daily summary of all the shitposting it did and funny memes it saw and stupid trivia it learned while I do more meaningful stuff with my life.

It’s a crazy dream, I know.

but also as a hapless crutch for endlesss neurodivergent layers of qualification.

I both resent and resemble that remark.

I love the train illustrations. I’m not sure they’re that meaningful or accurate, but OpenTTD is my jam so it earned my attention anyway. I guess healthchecks is cool too.

Subnet routing is generally far more complex than simply installing the client. If you aren’t succeeding at one you’re likely not going to succeed at the other.

I don’t know the exact problem based on what you’ve described and I’m not going to promise I can solve it for you but I’m going to try to give you some tools you can use to help yourself a little and hopefully be able to better understand what is going wrong and that will help you understand what you can do about it. Don’t get frustrated by this issue, this is a learning experience and this is a skill you need to invest in and develop so that you’re not just blindly copy-pasting instructions from videos (which is a bad place to be)

Step 1: Figure out where your tailscale.sh actually is.

Once inconsistency I noticed in your description of what’s going on is that you’re attempting to run tailscale.sh but you’re describing a path of /home/deck/documents/github/deck-tailscale.sh not sure if this is just a typo or what but that describes a file called deck-tailscale.sh which is not the same thing as tailscale.sh.

I think the repository you’ve downloaded based on those instructions is called deck-tailscale however a repository is a folder full of files, and tailscale.sh is ONE of those files. That repository’s name would probably be /home/deck/documents/github/deck-tailscale/ so if you’re looking for tailscale.sh inside that repository it will be /home/deck/documents/github/deck-tailscale/tailscale.sh. (two tailscales in the full path, one for the repo and one for the file itself)

You can verify all of these paths by using the ls <path> command, ls (that’s L and S, not IS) means “list” and is similar the dir command in Windows, it will show if the file you specify exists, or if it is a directory it will list all the contents of that directory. ls is a useful command to explore the directories and see which ones exist and which ones don’t. You can work your way up the path to see where things are going wrong, for example, if ls /home/deck/documents/github/deck-tailscale/ does not exist, try ls /home/deck/documents/github/ and if that doesn’t work try ls /home/deck/documents/ and so on

Second note: I notice your documents path is /home/deck/documents I don’t have a steam deck in front of me to check, but my Linux system has a documents folder called /home/<me>/Documents with a capital D. Paths on Linux are always case-sensitive. That means /documents is not the same thing as /Documents, which is not the same as /DOCUMENTS/ and if you attempt to use one when it’s actually the other, the file will not be found. Make sure the capitalization is correct in the whole path.

Step 2: Once you’ve located the correct path name of tailscale.sh you should be able to run it with: sudo <full-path-to-tailscale.sh>

Good luck.

Yup, they all have trailing slashes when viewed on Lemmy, and 3/4 have trailing slashes when viewed on piefed. So only piefed actually respects what was originally typed. Lemmy adds a trailing slash when you’re adding the comment, and also adds a trailing slash when reading a comment posted that doesn’t originally have a trailing slash. Intriguing (and slightly annoying).

Very interesting I wonder what happens if I post both trailing and non-trailing options, do they both get canonized into the same format?

https://piefed.ca/ – has a trailing slash https://piefed.ca/ – does not

Thank you for having me along on this journey. I don’t really know where it’s leading, but maybe it’s about the weird software behaviors we discover on the way.

The short answer: For a router, either find an off-the-shelf Wifi router that is supported by OpenWRT (very nice and very easy), or (and this is my personal preference) build your own firewall mini PC which will be much more complex and powerful to the point of complete overkill but also fully controllable right down to the network stack (and what’s the point of a homelab if not fiddling around with such things?).

You can run OpenWRT directly on full AMD64 PC if you want, or even just a Raspberry Pi (some people appear to have had good luck with the 4B and 5, though I don’t know the specifics of that approach) The famous PfSense would be another option, based on BSD. I used to use that, but I really wanted something directly Linux-based.

Which brings us to the fact that you can also even use a standard Linux distro like Debian and install all the tools you want on top of that and set up all the firewall yourself from scratch. That is actually what I do, using Linux kernel’s nftables for NAT Masquerading/IP forwarding and managing it currently with foomuuri which is essentially just a very lightweight nftables configuration manager. It doesn’t do anything you can’t do directly with nftables, but even though it’s perfect for me but I’m not sure I would recommend it in general. They have some very simple examples, but the documentation is pretty sparse, you need to either understand nftables under the hood or infer what you can by reading between the lines of the few examples you can find. A more mature and traditional Linux firewall like firewalld might be preferable if you want. Either way, this is definitely a much more complex route though, and fighting with firewall rules to get things to work is not everybody’s idea of “fun”. It is powerful though, and infinitely flexible. If you want it to “just work” without hassle, stick to the single-purpose devices and use OpenWRT as the OS designed to do this. It’s way simpler.

If you do decide do go the DIY firewall route though, all you really need for a firewall PC is at least a second NIC (some motherboards have two wired NIC onboard already, you can use one for WAN and the other + WiFi for LAN) or you can a PCIe network card that has multiple ports. I wouldn’t really recommend using one of your existing Mini PCs for this, as it’s really not a good idea to share the firewall/network appliance functionality shared with other services, both for security and for configuration complexity reasons. The firewall really works best and is easiest to configure when it is truly just a gateway for the network, putting traffic from one side out the other side, plus whatever fundamental network/firewall services you need to accomplish that. When you start also trying to selectively route some of that traffic to actual services on the firewall itself, it gets really complex and ugly really fast, and even if you can get it working which is often very nontrivial, it’s also very fragile and it’s easy to blow open holes in your security this way.

I’ve actually now got a pair of mini-PC firewalls, both set up using foomuuri, uCARP and Kea to do failover with each other so if one goes offline the other takes over its IP and starts routing traffic until it comes back. It’s not perfect or completely bulletproof but it’s pretty good for an amateur! In a pinch (when my previous, non-redundant firewall died) I’ve also used an GL.iNet travel router as my network’s primary router temporarily and their routers support an expansion board with 5G/SIM support so that could be an option too. I have to say it worked perfectly and was actually pretty nice, my only hesitation is that the travel router (at least the one I have, Beryl AX) seems to run a bit hot and I’m not sure it’s really intended for 24/7/365 operation (plus I need it for when I travel). They do make home routers too though, so maybe worth looking into, they’re really nice hardware running their own fork of OpenWRT out of the box.

You will likely have to use a temporary alternative until the name is removed so you can reclaim it. No idea how long that takes, it might not even happen automatically at all. It seems like there is a forum thread for it

Aha I see you did the text-based install then? I’ve never done that myself but I just tried it now and it worked fine for me with the default password it mentions. Make sure caps lock is off. You will not be able to see the password when you type it, so be extra careful you are typing it correctly.

Most of the same cautions about internet access still apply, if your networking is active on this VM there’s a non-zero chance you can get hacked right away when you’re in default passwords/initial setup mode. If you continue to have trouble getting in, you should reinstall it once again onto a fresh VM with network mode set to NAT if possible, or even disabled completely, and see if it works in that configuration. It really is critical to get the password set up before opening up the internet.

Not sure what you mean by “what was provided”… who is providing a username and password for your yunohost?

You are supposed to create your own username and password during the “Begin” setup process after it first installs. “root” and “yunohost” are very insecure and if you use passwords that are copy/pasted from somewhere else on a machine connected to the internet it will be hacked, potentially almost immediately. People have bots that literally just try to connect using these common default passwords all day every day to every site on the internet. I have literally had machines with such crappy passwords hacked within minutes of spinning them up. The same thing can happen even when you are first doing the setup process. If somebody else can get in, they can (most likely with a bot) do the setup process themselves and set up their OWN username/password, and now it will ask you for that password that THEY set, which you have no way of knowing. The instance belongs to the first person to claim it, and if that’s not you, you have to wipe it and start over.

Your yunohost VM interface should not be exposed to the internet during setup. Even briefly, or someone else can immediately compromise it like this. The only way to ensure you are the first person to access it is to make sure you are the ONLY person who can access it, until it is properly set up and secured. Bots are WAY faster than you can be.

Use localhost console, VM port forwarding or some other secure method of making sure nobody but your own host computer can access the IP of the server where you are setting things up, until it has a strong, secure password (not “yunohost”) and make sure you have all its security features configured and working before you even think about making it accessible to the internet.

For RAID that’s pretty much it as far as I know, but I’m pretty sure it can be a lot simpler and more flexible using some of these newfangled filesystems that are out nowadays like LVM and ZFS and maybe BTRFS? I can’t pretend I’m super up to date on all the latest technologies, I know they can do some really incredible stuff though. I’m not familiar enough to recommend it, but it might be worth looking into what they can do for you if your NAS supports it. From what I understand they don’t use RAID at all, although they might be able to simulate it, instead they treat disks as JBOD (just a bunch of disks) and use their own strategies to spread whole filesystems and partition structures across them in various safe and redundant ways that are way more flexible, that don’t care about disk size or anything like that, they’ll handle any shapes and sizes and I think they can be expanded and contracted pretty freely. I think ZFS in particular is really heavily used for this and supports some crazy complicated structures.