.forgejo/workflows | ||
hosts | ||
modules | ||
nix-secrets@4db84b723b | ||
packages | ||
.gitignore | ||
.gitmodules | ||
flake.lock | ||
flake.nix | ||
README.md |
NixOS Configuration
A full set of configuration files managed via NixOS. This project follows the general structure of https://github.com/tiredofit/nixos-config
Warning
DO NOT DOWNLOAD AND RUN
nixos-rebuild
ON THIS REPOSITORY! These are my personal configuration files. I invite you to look through them, modify them, and take inspiration from them, but if you runnixos-rebuild
, it will completely overwrite your current system!
Using this repo
Note on secrets management
Secrets are stored in a separate repo called nix-secrets
, which is included here as a flake input. This is a poor man's secret management solution, but y'know what, it works. These "secrets" will be readable to users on the system with access to the /nix/store/
, but for single-user systems, it's fine.
Initialize the submodule with:
git submodule update --init --recursive
First-time installation
To apply the config for the first time (e.g. on a fresh install), run these commands, replacing Shura
with the name of the host:
nix flake update
sudo nixos-rebuild switch --flake .#Shura
nix flake update
updates the flake.lock
file, which pins repositories to specific versions. Nix will then pull down any derivations it needs to meet the version.
Note
This config installs a Nix wrapper called nh. Basic install/upgrade commands can be run using
nh
, but more advanced stuff should usenixos-rebuild
.
Running updates
Periodically run nh
to update the system. Use the --update
flag to update flake.lock
as part of the process. Note that for subsequent builds, you can omit the hostname:
nh os boot --update
This is the equivalent of running:
nix flake update
sudo nixos-rebuild boot --flake .
There are a few different actions for handling the update:
switch
replaces the running system immediately.boot
switches to the new generation during the next reboot.build
creates and caches the update without applying it.test
creates the generation and switches to it, but doesn't add it to the bootloader.
Using Remote builds
Nix can create builds for or on remote systems, and transfer them via SSH.
Generating a build on a remote system
You can run a build on a remote server, then pull it down to the local system. This is called a distributedBuild
.
Note
For distributed builds, the root user on the local system needs SSH access to the build target. This is done automatically.
To enable root builds on a host, add this to its config:
nix.distributedBuilds = true;
For hosts where nix.distributedBuilds
is true, this repo automatically gives the local root user SSH access to an unprivileged user on the build systems. This is configured in nix-secrets
, but the build systems are defined in modules/base/nix.nix
.
Pushing a build to a remote system
Conversely, you can run a build on the local host, then push it to a remote system.
NIX_SSHOPTS="-o RequestTTY=force" nixos-rebuild --target-host user@example.com --use-remote-sudo switch
Testing without modifying the system
If you want to test without doing a whole build, or without modifying the current system, there are a couple additional tools to try.
Dry builds
To quickly validate your configuration, create a dry build. This analyzes your configuration to determine whether it'll actually build:
nixos-rebuild dry-build --flake .
Virtual machines
You can also build a virtual machine image to preview changes. The first command builds the VM, and the second runs it:
nixos-rebuild build-vm --flake .
./result/bin/run-nixos-vm
Note
Running the VM also creates a
.qcow2
file for data persistence. Remove this file after a while, otherwise data might persist between builds and muck things up.
Adding a host
To add a new host:
- Create a new folder in
hosts/
. - Copy
hosts/configuration.nix.template
into this folder and name itdefault.nix
. - Run
nixos-hardware-configuration
on the host and copy itshardware-configuration.nix
file here. You might also want to check theconfiguration.nix
generated by this command to see if there's anything you should import into your host'sdefault.nix
. - Configure
/hosts/<host>/default.nix
however you'd like. - Add the new host to
flake.nix
. - Run
nix flake update
andnixos-rebuild boot --flake .#<Hostname>
.
About this repository
Layout
This config uses two systems: Flakes, and Home-manager.
- Flakes are the entrypoint, via
flake.nix
. This is where Flake inputs and Flake-specific options get defined. - Home-manager configs live in the
users/
folders. - Modules are stored in
modules
. All of these files are automatically imported (except home-manager modules); you simply enable the ones you want to use, and disable the ones you don't. For example, to install Flatpak, sethost.ui.flatpak.enable = true;
.- After adding a new module, make sure to
git add
it.
- After adding a new module, make sure to
Features
This Nix config features:
- Flakes
- Home Manager
- AMD, Intel, and Raspberry Pi (ARM64) hardware configurations
- Workstation and server base system configurations
- GNOME desktop environment with KDE integrations
- Boot splash screens via Plymouth
- Secure Boot and TPM
- Disk encryption via LUKS
- Custom packages and systemd services
- Flatpaks
- Default ZSH shell using Oh My ZSH
- Secrets (in a janky hacky kinda way)