helpimnotdrowning

@helpimnotdrowning@lemmy.sdf.org

• ⁨Comment⁩ on ⁨How can I keep my forwarded port secure?⁩ ⁨⁨1⁩ ⁨week⁩ ago⁩:

  This might also become a hassle since basically all residential connections (likely of OPs friends) have dynamic IPs - if someone wants to join while OP is away, but their IP has changed since their last connection, now they have to wait on OP to update the firewall rules.

  Apart from getting your MSA token stolen, there’s not really much that can get around server login (yet). All online-mode logins pass through Microsoft (part of the reason why Xbox service outages seem to affect Minecraft so much).

  If your friends all individually seem to stay within some certain IP ranges (ex, first handful digits always stay the same, 12.34.56.xx), then I’d say go ahead with whitelisting them fully (ex, 12.34.56.xx --> 12.34.56.0/24, CIDR notation). If they jump around unpredictability, I would stick with the username-based whitelisting and online-mode-only.

• ⁨Comment⁩ on ⁨How can I keep my forwarded port secure?⁩ ⁨⁨1⁩ ⁨week⁩ ago⁩:

  as long you are only forwarding Minecraft’s 25565 port to your server machine, it should be fine. Just make sure to keep Online mode on, use the whitelist, and get your plugins from trusted sources. Otherwise I wouldn’t worry too much.

  I see others recommending VPN solutions like zerotier for your friends to connect to; I don’t personally feel like this is necessary, and (in my experience), making your friends do more technical setup than just connecting to the server is often a big turn-off.

  Bonus: If you ever take a peek at your server logs while it’s running (and exposed to the Internet, if you avoid said VPN solutions), you might notice a lot of weird connections from IPs and usernames you don’t recognize. These are server scanners and threat scanners that look for vulnerable servers to connect to and exploit. This is normal and you’ll be fine as long as you keep that whitelist and stay up-to-date on developments in the server admin space.

• ⁨Comment⁩ on ⁨Design patterns⁩ ⁨⁨2⁩ ⁨months⁩ ago⁩:

  I’ve acknowledged that, while convenient, my (small) setup is still a burden that I would be asking someone to take. If your friends don’t already share your passion or knowledge for Linux/Docker/the intricacies of <whatever you may be running>, I doubt they’d be willing to take on what you leave them.

  My friends had a family member who had a giant setup of Raspberry Pi’s that did Pi-hole, Home Assistant, F@H, among many other services and machines (there were like 6 Pi s!). They passed some time ago, and there’s just no one in the family who was willing to take on the responsibility to learn how to manage everything that was going on—services have been slowly degrading/going down since then.

  Those who rely on your services will just go back to using Google Drive, watch-anime-free.org.ru, and pressing “Open LAN world” in the Minecraft client. I don’t think it’s okay, but if you’re out of the game, you won’t be there to object.

  ---

  That is to say, if you DO have friends that are knowing and willing, you need to leave plenty of good documentation. I haven’t been one to write much of anything, and I’ve already fucked up my shell profiles again because of no documentation, but I can give some general pointers:

  • What runs where?
  • Why are things configured in certain ways? (ie “$GameServer gets 4gb because going over creates GC stutters”, “$IP is blocked because of telemetry”, “$File is symlinked to /dev/null to effectively delete/override a rule from $SomewhereElse”)
  • List rules and their exceptions. (ie “Service ports are numbered this way because it looks nice”, “Except $Port because it conflicts with $SystemService”)
  • List things even if they’re from personal preference (ie “Service ports are numbered this way because it looks nice”, tells user that these are effectively meaningless and things shouldn’t break by changing these, barring common sense)

  Basically, leave meaningful comments that explain why something is the way that it is. You should be able to use this documentation yourself as reference material. Keep this documentation updated regularly, as frequently quoted “bad documentation is worse than no documentation” (or something like that)

  (sorry if this last section in particular doesn’t make much sense, I haven’t slept in $hours. feel free to ask for clarification!)

• ⁨Comment⁩ on ⁨Nginx 502, ssh not working.⁩ ⁨⁨2⁩ ⁨months⁩ ago⁩:

  if your sister’s by your server in-person, maybe you could guide them to graphically install something like Rustdesk, give you the access code & have them manually accept the connection so you can get back in.

  You’ll be stuck streaming your terminal window and sending laggy keystrokes though whatever connection you have now (until you can get ssh running), but it’s better than nothing.