I take my shitposts very seriously.

  • 3 Posts
  • 207 Comments
Joined 3 years ago
cake
Cake day: June 24th, 2023

help-circle
  • Right at this moment, I’m rebuilding my homelab after a double HDD failure earlier this year.

    The previous build had a RAID 5 array of three 1TB Seagate Barracudas that I picked out of the scrap pile at work. I knew what I was getting into and only kept replaceable files on it. When one of the drives started doing the death rattle, I decided to yank some harder-to-acquire files to my 3TB desktop HDD before trying to resilver the entire array. Guess which device was the next to fail. I could mount and read it, but every operation took 2-5 minutes. SMART showed a reallocation count in the thousands. That drive contained some important files that I couldn’t replace, which were backed up to the (now dead) server. Fortunately ddrescue managed to recover damn near everything and I only lost 80 kilobytes out of the entire disk. That was a very expensive lesson that I’ve learned very cheaply.

    The new setup has a RAIDz1 pool of 3x 4TB Ironwolf disks (constrained by the available SATA sockets on the motherboard), plus a new SSD for the OS and 16GB RAM (upgraded from literally the first SSD I ever bought and 10GB mis-matched DDR3).

    Mounting it was a bit of a dilemma. The previous array was simply mounted to the filesystem from fstab and bind-mounted to the containers. I definitely wanted the storage to be managed from Proxmox’s web UI and to be able to create VDs and LXC volumes on it. Some community members helped me choose ZFS over LVM-on-RAID5. Setting up the correct permissions wasn’t as much of a headache as last time. I’ve just managed to get a Samba+NFS+HTTP file server and Jellyfin running and talking to each other. Forgejo and Nextcloud will be next.







  • If the other person has a Tailscale account, it sounds like the most expedient method is to simply invite them to the tailnet as a non-admin user with strict access control.

    You could share a node with an outside user, but I don’t know how much the quarantine would affect its functionality. You could also use Funnel to expose the node to the internet (essentially like a reverse proxy), but there are obvious vital security considerations with that approach.











  • Tailscale Funnel will let you expose a host to everyone on the internet. You’ll need the Tailscale client running on either the Jellyfin host or a reverse proxy pointing to it. Tailscale itself will act as a reverse proxy with TLS encryption, plus a DNS server.

    Exposing a service to the internet will always present some risk. You should definitely run your LXCs as unprivileged, unless needed otherwise, to mitigate the potential damage if an attacker escapes the container, or put the services in full virtual machines.



  • If you have IPv4 addresses, I guarantee you’re behind at least one NAT gateway. What you need is a Tailscale subnet router, or something equivalent from another service.

    In the most basic configuration, the Tailscale client facilitates communication (by using some UDP black magic fuckery) between one host it is running on and another host it is running on that are both connected to the same tailnet (the virtual network between Tailscale hosts). For this purpose, it uses addresses from the 100.64.0.0/10 “shared address space” subnet. These addresses will only be reachable from within your tailnet.

    If you want an entire subnet (e.g. your LAN) to be accessible within your tailnet, you need to set up a subnet router. This involves configuring the Tailscale client on a device within the target subnet to advertise routes (tailscale set --advertise-routes=192.168.1.0/24), allowing the host to advertise routes in the admin page (Machines -> -> Edit routes), and configuring the Tailscale client on external hosts to accept advertised routes (tailscale set --accept-routes).

    If you want your servers to be accessible from anywhere on the internet, you’ll need Tailscale Funnel. I don’t use it personally, but it seems to work. Make sure you understand the risks and challenges involved with exposing a service to the public if you want to choose this route.


  • Rolling release doesn’t mean that no testing is done. All updated packages are tested by maintainers before being released into the official repository. A rolling release simply means that there are no individually marked OS versions and you always get the latest packages.

    In contrast, take Debian for example. It uses a point release system with major named versions (e.g. Debian 13 “Trixie”), minor point releases (e.g. 13.1), and security and bugfix patches between those. New feature updates are released only between point releases, and breaking changes are only introduced between major versions. This allows the maintainers to practice a greater amount of care in testing that the packages work well together, but also means that new features are always held back to some extent. This does not happen in a rolling release system. All upstream changes are pulled, tested, and released, regardless of whether a breaking change is introduced.

    By its nature, a rolling release distribution will require a greater amount of maintenance. If a package update requires manual intervention, it will be published on archlinux.org. For as long as I’ve been a Linux user, I’ve only seen one package update that made systems temporarily unbootable, and I was saved from that by being a Manjaro user at the time.

    But, to answer the question, I usually update my home and work PCs (both Arch) about once every week or two, or as required by a new software or important security update.


  • It’s less about the concept of a game-centric headset and more about the brands that sell themselves as “We Are Gamers” with angular shapes and RGB out the ass. Steelseries, Razer, Alienware, Aorus, ROG… I’ve had many bad experiences both personally and professionally. The only one I didn’t end up regretting was Logitech G. The G502 mouse is a beast.