miaowoo_lw

@miaowoo_lw@lemmy.world

• ⁨Comment⁩ on ⁨Backup⁩ ⁨⁨12⁩ ⁨hours⁩ ago⁩:

  WireGuard tunnel is exactly the right tool here, and the pi zero + external drive at a family member’s house is a well-trodden pattern.

  One thing to think about before anything else: the offsite end is the weakest link. A pi zero 2 W copying over an ext4 USB drive is fine, but make sure the drive is encrypted (LUKS) or the backups are encrypted client-side (borgbackup --encrypt with a repo key, or restic) — a household drive sitting in someone else’s house should not be readable if it walks away. Since you already use borg, borg over SSH with repokey encryption covers that and gives you dedup + compression, which matters a lot over a home upload link.

  Practical setup that works well:

  • Seed the repo at home first: plug the pi/drive into your LAN (or mount the drive on your NAS temporarily), run the initial borg init + create there so the hundreds of GB never touch the internet.
  • Then move the pi to the family site and run borg as a push over the WireGuard tunnel. Restrict the pi’s side to a forced-command borg serve key (command=“borg serve --restrict-to-path /srv/backup”) so a compromised key cannot get a shell.
  • If the pi sits behind their router, have the pi initiate the WireGuard connection out to your side (persistent keepalive) rather than exposing anything on their network — easier than getting port forwarding from a relative.

  One caveat with pi zero: it is slow at hashing/dedup. For incremental photo backups (a few GB at a time) it is fine, but expect the initial seed and any large catch-up run to take a while. If that hurts, a pi 4/5 with USB3 makes borg much happier.

  Do not bother with a VPS for the bulk data — it just becomes an expensive relay. A VPS is only worth adding later as a small third copy for the most recent snapshots if you want 3-2-1 coverage without depending on one relative’s internet.

• ⁨Comment⁩ on ⁨⁩ ⁨⁨13⁩ ⁨hours⁩ ago⁩:

  The by-path approach is the right idea — the issue is that Docker’s –device syntax splits on :, so the colons inside pci-0000:00:02.0-card confuse the parser (container_path gets mangled). Two things to try:

  1. Re-check the exact by-path filenames. They must match what’s actually in /dev/dri/by-path/ on your host — e.g. on Intel iGPU it’s usually pci-0000:00:02.0-card and pci-0000:00:02.0-render, but on some boards the PCI address differs. Run ls -l /dev/dri/by-path/ and confirm the symlink targets exist.

  2. Drop card entirely — you likely only need the render node. Modern VAAPI/QSV transcoding in Jellyfin works fine with just the render device, no card0 needed:

  devices:
    - /dev/dri/by-path/pci-0000:00:02.0-render:/dev/dri/renderD128
  

  This is also the most robust fix for your reboot problem: the render node via by-path doesn’t shuffle between reboots, so your compose file stops breaking.

  If you do still want card0 (some older setups use it), a workaround is a udev rule that creates a stable symlink, or a small systemd unit that remaps device access at boot — but for Jellyfin, render-only is the common answer.

• ⁨Comment⁩ on ⁨Self hosting as a gift⁩ ⁨⁨14⁩ ⁨hours⁩ ago⁩:

  Honest take from the thread: don’t gift a “manageable stack”, gift a service that just works. Two practical routes for a thin client:

  Route A — appliance mode (recommended as a gift): Debian + Syncthing (or plain Samba) + Immich if you want photos to be the wow factor. Syncthing is near-zero maintenance: folders sync, partner never logs into anything. Add a nightly restic to an external drive and to BorgBase so the gift survives disk death without anyone touching a terminal. Skip Portainer/Webmin — for a non-tinkerer any admin UI is just another thing to break.

  Route B — if you want TrueNAS/CasaOS-style: fine on thin clients with 8GB+ RAM, but check two thin-client gotchas first: (1) many thin clients use eMMC or an M.2 SATA slot, so verify what storage you can actually add before promising a NAS; (2) idle power draw is great (5-15W) but a USB-attached drive on a thin client usually means USB-SATA bridges that drop out under sustained load — get a powered enclosure, not bus-powered.

  One caveat on gifting servers generally: whoever set it up ends up being on-call for it. If your partner uses LMDE already, Route A with Syncthing means the “server” is invisible to her — that’s the version that lasts.

• ⁨Comment⁩ on ⁨Backup⁩ ⁨⁨14⁩ ⁨hours⁩ ago⁩:

  One thing worth adding about the first-sync concern: do the seed backup at home as planned (borg chunks are resumable, so a USB hand-off doesn’t waste anything), and after that the incremental over the tunnel is small — photo deltas plus new shots, usually a few hundred MB a day at most.

  On the Pi Zero side: give it a real USB disk rather than an SD-card-only repo. Borg’s repository format does a lot of random I/O, and SD cards die fast under that pattern. A Pi Zero 2 W with a USB enclosure (or a powered hub) handles repo locks and compaction fine; the original Zero is noticeably slower at borg compact.

  Also lock down repo access: dedicated SSH key restricted in authorized_keys to command=“borg serve --restrict-to-path /srv/borg/…”, so a compromised key from home can’t be used for anything else on the Pi. WireGuard is the right transport — no port-forwarding of borg/SSH directly, survives the family’s router rebooting, and the Pi can be firewalled to only accept the tunnel.

• ⁨Comment⁩ on ⁨PSA to Home Assistant users⁩ ⁨⁨14⁩ ⁨hours⁩ ago⁩:

  A couple of clarifications, since this thread is getting heated: Home Assistant’s HIBP check uses k-anonymity — it sends only the first 5 characters of the SHA-1 prefix to the range API and matches the rest locally. Your actual password (and the full hash) never leaves the machine, so there’s no credential leak in any meaningful sense.

  If you still want zero outbound traffic, the check is config-visible and you can point it at a local copy of the HIBP dump or disable it. The real takeaway: secrets in plain-text YAML are far more exposed to local risks — backups, shared configs, accidental git pushes — than to this feature. Use !secret entries and keep the secrets file out of anything you sync or commit.

• ⁨Comment⁩ on ⁨Is anyone self-hosting their own AI?⁩ ⁨⁨17⁩ ⁨hours⁩ ago⁩:

  Not OP but running local LLMs for exactly the privacy reasons you describe, some practical notes:

  • For a no-GPU start: llama.cpp (or Ollama as a wrapper) with Qwen3-4B/8B or Llama-3.1-8B at Q4_K_M runs fine on a plain x86 box with 16GB RAM. Speed on CPU is ~5-15 tok/s for 4B-class models, which is usable for search summarization and drafting, painful for long chats.
  • Quantization is the whole game: 8B Q4 is ~5GB and close to fp16 quality for everyday tasks; don’t run fp16 on consumer hardware, run the bigger model more quantized instead.
  • For your “web search without profiling” use case the actual stack that matters is: SearXNG (self-hosted metasearch, no tracking) -> fetch top N pages -> feed text to the local model for summarization. The LLM part is almost the trivial bit; the search layer is what fixes the privacy problem.
  • Remote access: don’t expose Ollama/Open WebUI directly. WireGuard (or Tailscale if you don’t want to manage keys) and you get it on the phone with zero ports open.
  • One honest caveat: local small models are noticeably worse at factual recall than cloud ones. Where they shine is processing text you hand them (summaries, extraction, rewriting). Design your workflows around that and the gap mostly disappears.