• 0 Posts
  • 45 Comments
Joined 2 years ago
cake
Cake day: June 14th, 2023

help-circle





  • 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.






  • High clock speeds are not the same thing as high wattage, they aren’t even really related, or very closely associated. We have no idea what the power usage of these processors will be. They could even end up being more efficient than previous processors, doing more instructions in a shorter period of time then powering back down to idle sooner on the same workload. Yes people might decide to throw more work at them as a result, but that’s not the CPU’s fault, that’s a people problem not a hardware problem.


  • 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.



  • 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.


  • cecilkorik@lemmy.catoSelfhosted@lemmy.worldWhat do I do -- Incorrect?
    link
    fedilink
    English
    arrow-up
    8
    arrow-down
    1
    ·
    2 months ago

    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.






  • “I don’t know, that’s just how we’ve always done it.”

    In my experience there often is a reason for it, it’s just that the person who knew the reason for it left the company and it was never properly documented, so now it’s just cargo-cult-policy without any understanding behind it. So you’re right, there’s no way to figure out why it’s done that way or if it should continue to be done that way without thorough reexamination and a pretty analytical approach, and when those reasons are old they can certainly turn out to be badly outdated, but I’d also caution against just blanket assuming that it probably isn’t necessary simply because it’s “the way we’ve always done it” and no one seems to know why. The erosion of institutional knowledge is relentless, but that doesn’t mean it was never known or never for a good reason either. It’s not braindead to follow a policy you don’t understand the reason for, it might be lazy and it might be putting too much trust in the people who made the policies, but it’s not always wrong. Sometimes the policies are written in blood, and you not knowing that doesn’t mean it’s not a good policy.