• 0 Posts
  • 67 Comments
Joined 2 months ago
cake
Cake day: February 5th, 2025

help-circle

  • The new service includes a WiFi 7 router

    I don’t recommend it.

    I would shoot for a 4 port 2.5Gbe unmanaged switch with 2 SFP+ ports (6 total ports) for 10G networking. 2.5Gbe is going to be more than enough for any WiFi solution you choose with room to upgrade 10G to WiFi if you wanted to spend a bit more on a higher tier WiFi router still leaving a single SFP+ port for 10G networking from your PC.

    Biggest hit for your buck. Gonna set you back $40-50.

    but if I ever wanted to get the max out of it, what does that take?

    Kind of a lot. At least a top to bottom upgrade, from modem (PON), to 10G networking, to new Ethernet cables, to new 10G network drivers. Looking at a few hundred if you do it right. I also had Optimum’s 8Gbps internet and was never able to even get anywhere near advertised speeds due to network saturation. IMO, the upgrade right now is too expensive to justify the expense for what you get. If you were confident you would be able to max out the connection, that would be a different story. But ultimately it’s gonna be up to you. If you don’t mind dropping a few hundred on upgrades, then go nuts.


  • Again, they’re not denying you entry permanently, but they absolutely can slow fuck you for weeks until your device is unlocked and checked. You people live in some little utopia that doesn’t exist.

    We just deported a US citizen to Argentina without due process and its taking a federal court order for the US government to do anything about it. You really think they care about your “right” to reenter the country?


  • Reasoning skills and experience. There are entire botnets dedicated to finding servers with open SSH ports on 22. If the bots can connect, the IP of the server will be added to a list to be brute forced.

    I’m a per diem linux systems administrator. Right now I have a VPS that I setup myself. It uses a non-standard ssh port, fail2ban, and rejects incoming connections to port 22. According to connection logs, I get about 200 attempts per 24 hours from bots randomly pinging ports to see if they can catch an open SSH port–and they’re banned via fail2ban.

    I checked out some other servers that I manage, which I did not setup and have no control over how they operate. Sifting through just 3 random servers and checking connection logs, they have a combined 435,000 connection attempts in the past 6 hours between the 3 of them. These are relatively small servers with an extremely small presence. Simple fact of the matter is, is that they all have port 22 open and reachable. So botnets attempt to brute force them.

    So just anecdotally that’s a difference of 0.0459770115% or 99.96%. Anyone telling you that changing the default SSH port doesn’t do anything for security has absolutely no practical experience at all. It significantly reduces your attack surface as bots have to guess at ports until they find your SSHd’s operational port to even begin to start sending attempts.


  • Pursuant to CBP’s border search authority explained above, when presenting their effects for inspection, all travelers are obligated to present their electronic devices and the information resident on the device in a condition that allows for the examination of the device and its contents. If the electronic device cannot be inspected because it is protected by a passcode or encryption or other security mechanism, that device may be subject to exclusion, detention, or other appropriate action or disposition. Additionally, the traveler may face longer processing times to allow for CBP to access the contents of the device.

    Taken directly from CBP’s website; regardless of any citizenship, or nationality, they can refuse to let you reenter the country until your device is searched. Period. I don’t know where this idea that “I’m an American, they can’t refuse to let me back into my own country!” narrative came from, but it is entirely fictitious. There are dozens of reasons for you to be refused reentry.


  • Locking down your phone does nothing for you… If they see that you have a phone and they can’t access it they simply won’t let you in the country regardless of who you are.

    The only solution to this is to simply not have an electronic device when going through customs.

    Overnight your cell phone to yourself if you’re that worried about it. Any other solution is superfluous and outright stupid.

    If you’re entering the US through Mexico and they demand you unlock your phone and you refuse or it’s “locked down” you don’t win that conflict. You’re just a permanent resident of Mexico now because you’re not getting into the United States regardless of your citizenship status.


  • And I’m a CEHv7. A literal security professional–and I say that an overwhelming vast majority of attacks against servers using SSH are going to come over the default port. Quite literally 99%. This means that you can lower your attack surface by exactly 99% by simply changing the default SSH port…

    Those posts provide no meaningful insight and what they say is by the very technical of all interpretations is correct, I absolutely disagree with these statements. What they mean to say is that simply changing the default SSH port isn’t alone I means of strictly protecting yourself. Meaning you shouldn’t change the default SSH port and think that your server is secured because it’s not.

    Quite the different interpretation than me saying it should be mandatorily a part of your security strategy.

    In protecting yourself against port scanning is trivial.

    Anyone underestimating the power of changing The default SSH port is someone who’s opinion I can safely disregard.




  • consumer motherboards don’t have that many PCIe slots

    The number of PCIe slots isn’t the most limiting factor when it comes to consumer motherboards. It’s the number of PCIe lanes that are supported by your CPU and the motherboard has access to.

    It’s difficult to find non-server focused hardware that can do something like this because you need a significant number of PCIe lanes to accommodate your CPU, and your several GPUs at full speed. Using an M.2 SSD? Even more difficult.

    Your 1 GPU per machine is a decent approach. Using a Kubernetes cluster with device plugins is likely the best way to accomplish what you want here. It would involve setting up your cluster, installing the drivers for your GPU (on each node) which then exposes the device to the system. Then when you create your Ollama container, in the prestart hook, ensure you expose your GPUs to the container for usage.

    The issue with doing this, is 10Gbe is very slow compared to your GPU via PCIe. You’re networking all these GPUs to do some cool stuff, but then you’re severely bottle-necking yourself with your network. All in all, it’s not a very good plan.


  • Xanza@lemm.eetoSelfhosted@lemmy.worldTIL - Caddy
    link
    fedilink
    English
    arrow-up
    4
    ·
    3 days ago

    I like to use a justfile to do this all in one fell swoop;

    default:
      just --list
    
    caddy-refresh:
      caddy fmt --overwrite ~/.caddy
      caddy validate --config /etc/caddy/Caddyfile -a caddyfile
    caddy-reload: caddy-refresh
      doas docker exec -it caddy caddy reload --config /etc/caddy/Caddyfile
    

    ~/.caddy is my caddyfile, which is system linked to /etc/caddy/Caddyfile. Doing it this way ensures there are no permission issues, and you don’t need sudo to edit your caddyfile. So you simply nvim ~/.caddy, make your changes, and then run just caddy-reload, which runs caddy-refresh before reloading the caddy config via docker.

    Works great, and only involves one command.









  • The biggest issue I have with Caddy and running ancillary services as some services attempt to utilize port 80 and/or 443 (and may not be configurable), which of course isn’t possible because Caddy monopolizes those ports. The best solution to this I’ve found is to migrate Caddy and my services to docker containers and adding them all to the same “caddy” network.

    With your caddy instance still monopolizing port 80 and 443, you can use the Docker expose or port parameters to allow your containers to utilize port 80 and/or 443 from within the container, but proxify it on the host network. This is what my caddy config looks like;

    {
            admin 127.0.0.1:2019
            email {email}
            acme_dns cloudflare {token}
    }
    domain.dev, domain.one {
            encode zstd gzip
            redir https://google.com/
    }
    *.domain.dev, *.domain.one {
            encode zstd gzip
            @book host bk.domain.dev bk.domain.one
            handle @book {
                    reverse_proxy linkding:9090
            }
            @git host git.domain.dev git.domain.one
            handle @git {
                    reverse_proxy rgit:8000
            }
            @jelly host jelly.domain.dev jelly.domain.one
            handle @jelly {
                    reverse_proxy {ip}:8096
            }
            @status host status.domain.dev status.domain.one
            handle @status {
                    reverse_proxy status:3000
            }
            @wg host wg.domain.dev wg.domain.one
            handle @wg {
                    reverse_proxy wg:51820
            }
            @ping host ping.domain.dev ping.domain.one
            handle @ping {
                    respond "pong!"
            }
    }
    

    It works very well.