Files
nix-config/hosts
ryan4yin | 二花 6e0d44c50d feat(nixos): manage scattered trash dirs with trash-cli retention timer (#265)
* feat(nushell): add trash command using the home trash can

On a tmpfs root with persistent dirs bind-mounted in, `rm --trash`
scatters items into per-mount .Trash-$uid dirs that file managers never
show, and gio refuses to trash on those internal mounts.

Add a `trash` command implementing the freedesktop trash spec
'failsafe' mode: items are moved to ~/.local/share/Trash with
spec-compliant .trashinfo entries, so Thunar can list and restore them.

Also preserve ~/.local/share/Trash on idols-ai so the trash survives
reboots.

* feat(nixos): manage scattered trash dirs with trash-cli retention timer

Replace the hand-written nushell trash command with the established
trash-cli tooling. On a tmpfs root with persistent dirs bind-mounted
in, the trash crate (nushell rm --trash) scatters items into per-mount
.Trash-$uid dirs that file managers never show and nothing cleans up.

- add trash-cli to system packages: trash-list scans/trash-restore
  handles every mount point's trash dir
- daily systemd timer runs 'trash-empty 30 -f', purging items older
  than 30 days across the home trash and all mount points
- drop the hand-written trash.nu module
- note in preservation.nix: do NOT persist ~/.local/share/Trash; a
  bind-mounted trash dir breaks the trash crate's home-topdir match
  for files straight under $HOME (it would try /.Trash-$uid, EACCES)

* fix(nixos): order trash-empty after preservation.target

The scattered .Trash-$uid dirs live inside the preservation bind
mounts, which use DefaultDependencies=no and are therefore NOT ordered
after local-fs.target. Add preservation.target to After= so trash-empty
only runs once all those mounts are up.
2026-08-23 23:40:53 +08:00
..
2026-07-17 10:39:53 +08:00

Hosts

This directory contains all host-specific configurations for my NixOS and macOS systems.

Current Host Inventory

Physical Machines

idols - Main Workstations

Named after characters from "Oshi no Ko":

Host Platform Hardware Purpose Status
ai NixOS i5-13600KF + RTX 4090 Gaming & Daily Use Active
aquamarine KubeVirt VM Virtual Monitoring & Services Active
kana NixOS Virtual Reserved Not Used
ruby NixOS Virtual Reserved Not Used

darwin - macOS Systems

Named after characters from "Frieren: Beyond Journey's End":

Host Platform Hardware Purpose Status
fern macOS MacBook Pro M2 13" 16GB Personal Use Active
frieren macOS MacBook Pro M4Pro 14" 48GB Work Use Active

12kingdoms - Homelab Servers & Apple Silicon Linux

Named after "Twelve Kingdoms":

Host Platform Hardware Purpose Status
shoukei NixOS MacBook Pro M2 NixOS on Apple Silicon Active
shoryu NixOS MoreFine S500Plus (AMD Ryzen 9 5900HX) KubeVirt Host & K3s Master Active
shushou NixOS MinisForum UM560 (AMD Ryzen 5 5625U) KubeVirt Host & K3s Master Active
youko NixOS MinisForum HX99G (AMD Ryzen 9 6900HX) KubeVirt Host & K3s Master Active

Virtual Machines & Clusters

k8s - Kubernetes Infrastructure

  • KubeVirt Cluster: 3 physical mini PCs (shoryu, shushou, youko) running all VMs
  • K3s Production: 3 masters + 3 workers for production workloads
  • K3s Testing: 3 masters for testing and development

External Systems

All my riscv64 hosts:

Naming Conventions

  • idols: Characters from "Oshi no Ko" anime/manga
  • 12kingdoms: Characters from "Twelve Kingdoms" anime/novel series
  • darwin: Characters from "Frieren: Beyond Journey's End" anime/manga
  • k8s: Kubernetes-related systems follow standard naming patterns

How to Add a New Host

The easiest way to add a new host is to copy and adapt an existing similar configuration. All host configurations follow similar patterns but are customized for specific hardware and use cases.

General Process

  1. Identify a similar existing host from the directory structure above
  2. Copy the entire directory and rename it for your new host
  3. Adapt the configuration files for your specific hardware and requirements
  4. Update references in the flake outputs and networking configuration

Essential Steps

  1. Under hosts/
    1. Create a new folder under hosts/ with the name of the new host.
    2. Create & add the new host's hardware-configuration.nix to the new folder, and add the new host's configuration.nix to hosts/<name>/default.nix.
    3. If the new host need to use home-manager, add its custom config into home/hosts/linux/<name>.nix or home/hosts/darwin/<name>.nix.
  2. Under outputs/
    1. Add a new nix file named outputs/<system-architecture>/src/<name>.nix.
    2. Copy the content from one of the existing similar host, and modify it to fit the new host.
      1. Usually, you only need to modify the name and tags fields.
    3. [Optional] Add a new unit test file under outputs/<system-architecture>/tests/<name>.nix to test the new host's nix file.
    4. [Optional] Add a new integration test file under outputs/<system-architecture>/integration-tests/<name>.nix to test whether the new host's nix config can be built and deployed correctly.
  3. Under vars/networking.nix
    1. Add the new host's static IP address.
    2. Skip this step if the new host is not in the local network or is a mobile device.

File Templates

Use existing hosts as templates. The key files typically include:

  • default.nix - Main host configuration
  • hardware-configuration.nix - Auto-generated hardware settings
  • Platform-specific files (e.g., nvidia.nix, apple-silicon.nix, etc.)

Examples to Reference

  • Desktop systems: See idols-ai/ for gaming/workstation setup
  • Server systems: See kubevirt-shoryu/ for K8s/KubeVirt hosts
  • macOS systems: See darwin-fern/ for macOS configurations
  • Apple Silicon: See 12kingdoms-shoukei/ for ARM Linux setup

Distributed Building

I usually run the build command on Ai and nix will distribute the build to other NixOS machines, which is convenient and fast.

When building some packages for riscv64 or aarch64, I often have no cache available because of various changes under the hood, so I need to build much more packages than usual, which is one of the reasons why the cluster was originally built, and another reason is distributed building is cool!

References

Oshi no Ko 【推しの子】 - Wikipedia:

The Rolling Girls【ローリング☆ガールズ】 - Wikipedia:

List of Twelve Kingdoms characters

List of Frieren characters