• 2 Posts
  • 80 Comments
Joined 7 days ago
cake
Cake day: January 6th, 2026

help-circle

  • Filling some gaps:

    systemctl enable --now firewalld unattended-upgrades  
    

    Read through /etc/firewall/firewalld.conf, especially the part about how containers might bypass your firewall if you don’t change defaults.

    Also rootless podman should run well out of the box as a mostly drop-in replacement for docker (meanwhile docker also does rootless now) and allows you to run the container runtime unprivileged. This is more secure than adding user to docker (effectively root) group. Setting up autostart by writing systemd .service unit files works the same for both Docker and Podman.


  • Had a fun one when I put an 8x card forking into two nvme drives in a mobo that I thought compatible. No matter what, only one of them connects. Turned out:

    • The 8x slot didn’t bifurcate at all
    • The secondary 16x slot could do up to 8x4x4. Which is the same as no bifurcation for an 8x card in that slot.
    • GPU only works in the primary slot

    You think you think of everything…


  • I have a few different makes of these and have been surprised by how big PSU I had to put (versus on-the-wall measured wattage) for them to not occasionally randomly fail and cutting a drive off until reboot. I guess it’s spikes they don’t handle well. Besides that, the cards themselves obviously add some overhead in that department. Something to consider if low-power is a priority.

    There has also been one or two drives that just wouldn’t work at all with either card, but were fine in individual slots. Vaguely suspecting drive firmware there.

    They do serve their purpose well but just to add some catches for anyone eyeing them. Startech is the brand I had the least glitches with FWIW but keep in mind that’s just one anecdote.

    Also ask yourself if you really need PCIe4 because the PCIe3 models are quite a bit cheaper, cooler and more stable.

    Oh, and make sure your motherboard supports PCIe bifurcation. Especially for older computers that’s not always a given.



  • kumi@feddit.onlinetoSelfhosted@lemmy.worldHomelab hardware choices
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    15 hours ago

    Odroid H4+ (Intel N97 4c; comparable to the CPU of that Protectli) and H4 Ultra (Intel N300 8c) also worth considering. Versatile units from a small established Korean maker.

    https://www.hardkernel.com/shop/odroid-h4-plus/

    https://www.hardkernel.com/shop/odroid-h4-plus/

    https://www.hardkernel.com/shop/h3-h2-net-card-2/

    If you plan on virtualizing or running a bunch of containers on it I think it’s worth looking at the higher-core models and more RAM. If it’s just for OPNSense, such 4c with 8G should be plenty.

    Also, if you can afford, I strongly suggest getting two of whatever you go for and not doing anything important with the secondary. It really sucks if you have some unexpected issue (hardware failures and OS regressions can happen to anything) and don’t have anything on hand to replace your main router with. Since you’ll be labbing it can also be very freeing to have a testing/dev/staging/playground/debugging device with the same hardware and messing around won’t take down your production network. IMO this is higher priority than higher specs if you have to do tradeoffs.


  • USB enclosures tend to be less reliable compared to SATA in general but I think that is just FUD. It’s not like that’s particularly bad for software RAID compared to running with the enclosure without any RAID.

    The main argument for not doing that is I believe mechanical: Having more moving parts mean things might, well, move, unseating cables and leading to janky connections and possibly resulting failure.

    You will kill your USB controller, and/or the IO boards in the enclosures

    wat.jpeg

    Source: 10+ years of ZFS and mdadm RAID on USB-SATA adapters of varying dodginess in harsh environments. Of course errors happen (99% it’s either a jiggly cable, buggy firmware/driver, or your normal drive failure) but nothing close to what you speak of.

    Your hardware is not going to become damaged from doing software RAID over USB.

    That aside, the whole project of buying new 4TB HDDs for a laptop today just seems misguided. I know times are tight but JFC why not get either SSDs or bigger drives instead, or if nothing else at least a proper enclosure.




  • The OP is about hosting forwarding or recursive DNS for lookups, not authoritatative DNS hosting (which would be yet at least one separate server).

    I count two servers (one clusterable for HA). How is that a lot for a small LAN?

    More would also be normal for serving one domain internally and publicly. Each of these can be separate:

    • Internal authoriative for internal domain
    • Internal resolvers for internal machines
    • Internal source-of-truth for serving your zone publicly (may or may not be an actual DNS server)
    • Public-facing authoritative for your zone serving the above
    • Secondary for the above
    • Recursing resolver of external domains for internal use

    Some people then add another forwarding resolver like dnsmasq on each server.


  • It seems the DHCP is handing out the fire wall’s ip for DNS server, 100.100.100.1 is that the expected behavior since DNSmasq should be forwarding to TDNS 100.100.100.333. Why not just hand out the TDNS address?

    You could and that should work but then it’s not called forwarding anymore. It does forwarding because that’s what you configured. Both approaches are valid.

    I have an opnsense firewall with DNSmasq performing DHCP and DNS forwarding to the Technitium server








  • Right, there’s the immutable root aspect. Guessing the other answer you got fills in the missing piece there and that Silverblue perhaps mounts the system flatpaks on a different r/w filesystem than the read-only /. Check output of mount to see.

    At the end of the day it’s up to you if you prefer to keep the system clean and run flatpak unprivileged, or centralize updates under root.

    The one catch I can think of with flatpak --user is that it obviously won’t work if /home is mounted with noexec, which is otherwise a good security measure (and IMO not doing that defeats a lot of the security wins of immutable distros). Unless you apply the same mounting strategy to the flatpak xdg user dirs, which is certainly an option but not something everyone will bother with. But then again maybe that’s exactly what you want anyway to make your Flatpak installations smoothly portable across distros.