README.md: cleanup

This commit is contained in:
Colin 2023-04-29 23:01:37 +00:00
parent 0c59f4e59c
commit dfa921035d

140
README.md
View File

@ -1,80 +1,94 @@
to deploy: ## What's Here
```sh this is the top-level repo from which i configure/deploy all my NixOS machines:
nixos-rebuild --flake ".#servo" {build,switch} - desktop
``` - laptop
- server
- mobile phone
if the target is the same as the host, nix will grab the hostname automatically: i enjoy a monorepo approach. this repo references nixpkgs, a couple 3rd party
nix modules like `sops`, the sources for <https://uninsane.org>, and that's
about it. custom derivations and modules (some of which i try to upstream) live
directly here; even the sources for those packages is often kept here too.
```sh ## Layout
nixos-rebuild --flake . {build,switch} - `hosts/`
``` - the bulk of config which isn't factored with external use in mind.
- that is, if you were to add this repo to a flake.nix for your own use,
more options (like building packages defined in this repo): you won't likely be depending on anything in this directory.
- `modules/`
```sh - config which is gated behind `enable` flags, in similar style to nixpkgs'
nix flake show `nixos/` directory.
``` - if you depend on this repo, it's most likely for something in this directory.
- `nixpatches/`
- literally, diffs i apply atop upstream nixpkgs before performing further eval.
- `overlays/`
- exposed via the `overlays` output in `flake.nix`.
- predominantly a list of `callPackage` directives.
- `pkgs/`
- derivations for things not yet packaged in nixpkgs.
- derivations for things from nixpkgs which i need to `override` for some reason.
- inline code for wholly custom packages (e.g. `pkgs/sane-scripts/` for CLI tools
that are highly specific to my setup).
- `scripts/`
- scripts which are referenced by other things in this repo.
- these aren't generally user-facing, but they're factored out so that they can
be invoked directly when i need to debug.
- `secrets/`
- encrypted keys, API tokens, anything which one or more of my machines needs
read access to but shouldn't be world-readable.
- not much to see here
- `templates/`
- exposed via the `templates` output in `flake.nix`.
- used to instantiate short-lived environments.
- used to auto-fill the boiler-plate portions of new packages.
## secrets ## Key Points of Interest
i use [sops](https://github.com/Mic92/sops-nix) for secrets. i.e. you might find value in using these in your own config:
see `hosts/common/secrets.nix` for some tips.
## building images - `modules/fs/`
- use this to statically define leafs and nodes anywhere in the filesystem,
not just inside `/nix/store`.
- e.g. specify that `/var/www` should be:
- owned by a specific user/group
- set to a specific mode
- symlinked to some other path
- populated with some statically-defined data
- populated according to some script
- created as a dependency of some service (e.g. `nginx`)
- values defined here are applied neither at evaluation time _nor_ at activation time.
- rather, they become systemd services.
- systemd manages dependencies
- e.g. link `/var/www -> /mnt/my-drive/www` only _after_ `/mnt/my-drive/www` appears)
- this is akin to using Home Manager's file API -- the part which lets you
statically define `~/.config` files -- just with a different philosophy.
- `modules/persist/`
- my alternative to the Impermanence module.
- this builds atop `modules/fs/` to achieve things stock impermanence can't:
- persist things to encrypted storage which is unlocked at login time (pam_mount).
- "persist" cache directories -- to free up RAM -- but auto-wipe them on mount
and encrypt them to ephemeral keys so they're unreadable post shutdown/unmount.
- `modules/programs.nix`
- like nixpkgs' `programs` options, but allows both system-wide or per-user deployment.
- allows `fs` and `persist` config values to be gated behind program deployment:
- e.g. `/home/<user>/.mozilla/firefox` is persisted only for users who
`sane.programs.firefox.enableFor.user."<user>" = true;`
- `modules/users.nix`
- convenience layer atop the above modules so that you can just write
`fs.".config/git"` instead of `fs."/home/colin/.config/git"`
to build a distributable image (GPT-formatted image with rootfs and /boot partition): some things in here could easily find broader use. if you would find benefit in
```sh them being factored out of my config, message me and we could work to make that happen.
nix build ./#imgs.lappy
```
this can then be `dd`'d onto a disk and directly booted from a EFI system.
there's some post-processing to do before running a rebuild on the deployed system (deploying ssh keys, optionally changing fs UUIDs, etc).
refer to flake.nix for more details.
## remote deployment ## Using This Repo In Your Own Config
some of my systems support cross compilation (i.e. building from x86-64 for an aarch64 host without using emulation).
- `nixos-rebuild --flake '.#cross-moby' build`
- `sudo nix sign-paths -r -k /run/secrets/nix_serve_privkey $(readlink ./result)`
- `nixos-rebuild --flake '.#cross-moby' switch --target-host colin@moby --use-remote-sudo`
## building packages
build anything with
```
nix build .#<pkgname>
```
specifically, i pass the full package closure to the `legacyPackages` flake output. that includes both my own packages and upstream packages.
on the other hand the `packages` output contains only my own packages.
in addition, my packages are placed into both the global scope and a `sane` scope.
so use the scoped path when you want to be explicit.
```
nix build sane.linux-megous
```
to build a package precisely how a specific host would see it (in case the host's config customizes it):
```
nix build '.#host-pkgs.moby-cross.xdg-utils'
```
## using this repo in your own config
this should be a pretty "standard" flake. just reference it, and import either this should be a pretty "standard" flake. just reference it, and import either
- `nixosModules.sane` (for the modules) - `nixosModules.sane` (for the modules)
- `overlays.pkgs` (for the packages) - `overlays.pkgs` (for the packages)
`nixosModules.sane` corresponds to everything in the `modules/` directory. ## Contact
it's a mix of broad and narrow scope options.
e.g. `sane.fs` is a completely standalone thing,
whereas `sane.web-browser` is highly personalized and doesn't *really* make sense to export.
regardless of scope, i do try to ensure that everything in `modules/` is hidden behind some enable flag
so that the disorganization isn't that critical.
## contact
if you want to contact me for questions, or collaborate to split something useful into a shared repo, etc, if you want to contact me for questions, or collaborate to split something useful into a shared repo, etc,
you can reach me via any method listed [here](https://uninsane.org/about). you can reach me via any method listed [here](https://uninsane.org/about).