This repository has no description
0

Configure Feed

Select the types of activity you want to include in your feed.

1# CLAUDE.md 2 3This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. 4 5## Repository Overview 6 7This is lassulus's personal NixOS/nix-darwin configuration repository, built on clan-core for managing multiple machines. It includes: 8- Multiple machine configurations in `machines/` 9- Configuration modules in `configs/` and `modules/` 10- Custom packages in `pkgs/` 11- packages which could in theory be upstreamed to nixkgs should go into the pkgs folder, in the tools folder we add tools we write ourself which are more complex or not upstreamable 12 13## Key Architecture Components 14 15### Machine Management 16- **Clan-core**: Primary framework for managing multiple machines 17- **Secrets**: Uses password-store for secrets management via clan.core.vars 18 19### Network Overlays 20The repository manages multiple overlay networks: 21- **Tor**: Anonymous network access 22 23### Module System 24- `configs/`: Main configuration modules 25- `configs/default.nix`: imported by all machines 26- `modules/`: Custom NixOS module definitions 27- Stockholm modules are also imported for krebs infrastructure 28 29## Common Development Commands 30 31```bash 32# Enter development shell 33nix develop 34 35# Deploy a NixOS machine (tools/deploy): one Secure Enclave unlock for all 36# secrets, builds on the target, shows source/closure diff, asks before 37# switching. `s` runs apps from ~/src/superconfig, so pass --flake to deploy 38# a different checkout/worktree. NEVER use `clan machines update`: it 39# decrypts each secret separately and fails on the Secure Enclave prompt. 40s deploy --flake . <MACHINE_NAME> 41 42# Format code 43nix fmt 44 45# Build NixOS configuration 46nix build .#nixosConfigurations.<machine-name>.config.system.build.toplevel 47 48# Build Darwin configuration 49nix build .#darwinConfigurations.barnacle.system 50 51# Deploy/rebuild Darwin configuration (for barnacle) 52sudo darwin-rebuild switch --flake .#barnacle 53 54# Access machines via SSH (as root, see below) 55ssh root@<machine-name>.r # via retiolum 56ssh root@<machine-name>.s # via spora 57ssh root@<machine-name>.n # via nether 58torify ssh root@$(pass show machines/<machine-name>/tor-hostname) # via tor 59``` 60 61## Remote Machine Access 62 63**CRITICAL**: For privileged work on a remote machine (firewall rules, 64journals of system services, systemctl, reading /run/secrets, ...), ssh in as 65root (`ssh root@<machine>.r`). NEVER use `sudo` on remote systems. Ssh as the 66normal user (`lass@`) only to act as that user, e.g. to run user tools. 67 68## Important: Git Staging for Flake Evaluation 69 70**CRITICAL**: New nix files must be staged (git add) before they are available in flake evaluation. When creating new packages, modules, or any nix files, always run `git add <files>` before testing with `nix build`, `nix run`, etc. 71 72## Git Push Policy 73 74**CRITICAL**: NEVER `git push` to any remote. Local commits are fine when asked. 75A push happens only when the user runs it themselves or explicitly says 76"push" for that specific change in the current conversation. This includes 77all remotes (origin, HTTPS via gh credentials, pair) and all branches. 78 79## Machine Facts and Secrets via vars 80 81- SSH public keys 82- Network identities (retiolum, mycelium, zerotier) 83- Syncthing IDs 84- DKIM keys (for mail servers) 85 86Secrets are managed via password-store and uploaded to `/run/secrets` on deployment. 87 88## Adding New Machines 89 901. Create directory `machines/<name>/` 912. Add `config.nix`, `physical.nix`, and optionally `disk.nix` 923. Generate facts using clan-cli 934. Add to inventory in `flake.nix` 945. Deploy using `s deploy --flake . <name>` 95 96## Pre-Commit 97 98**CRITICAL**: Always run `nix fmt` before committing to ensure all files pass the treefmt formatting check in CI. 99 100## Commit Message Guidelines 101 102- Use simple, descriptive commit messages without attribution footers 103- Use flake attribute paths as prefixes (e.g., `tools.mutt:` not just `mutt:`) 104- For flake.lock updates, use: "flake.lock: update" 105- Follow existing patterns seen in git log