fujin/Nixos
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
109 Commits 1 Branch 0 Tags
b471966e8aca58c9c2acd25f425db7984b59570d
T
Clone
Open with VS Code Open with VSCodium Open with Intellij IDEA
Download ZIP Download TAR.GZ Download BUNDLE

README.org

Installing NixOS on a Proxmox VM using nixos-anywhere

Abstract This guide documents methods for installing NixOS on a Proxmox virtual machine and a bare-metal machine (Fujin). It covers remote deployment, bare-metal installation with Disko, and building Proxmox image templates. It also covers post-installation steps for secrets management with sops-nix and lists available custom modules.

TL;DR: Fujin Quick Install (Bare Metal)

  1. Boot Live Environment: Boot into a NixOS installer or another Linux environment (like Izanami).

  2. Clone Repo: Clone this repository.

    git clone https://github.com/LichHunter/nixos

  3. Install with Disko: Run the Disko installer script for the minimal configuration.

    nix run github:nix-community/disko#disko-install -- --flake .#fujin-minimal --disk main /dev/nvme0n1
  4. Reboot & Setup: Reboot into the new system. Mount your backup drive, restore your SSH keys, and clone the repository again.

  5. Setup Root SSH for Remote Builds: Generate SSH key for root user to enable remote builds.

    sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519

  6. Update Izanagi Configuration: Add the new root public key to izanagi's authorized keys for remote builds.

    sudo cat /root/.ssh/id_ed25519.pub
# Copy this key and add it to machines/izanagi/default.nix in the openssh.authorizedKeys.keys section

  7. Rebuild to Main Config: Use the custom script to switch to the full configuration.

    ./bin/rebuild.sh boot

TL;DR: Proxmox Quick Install (Remote)

  1. Prepare VM: Boot the target Proxmox VM from a NixOS ISO and set a root password:

    passwd

  2. Deploy NixOS: From your workstation, run nixos-anywhere.

    nix run github:nix-community/nixos-anywhere -- --flake .#your-machine-name --target-host root@<vm-ip-address>

  3. Manage Secrets: Get the host's AGE key, add it to .sops.yaml, and re-encrypt.

    sops updatekeys secrets/secrets.yaml

Table of Contents   TOC

Fujin Installation (Bare Metal)

Boot Drive Installation

  1. Boot into izanami or another suitable Linux live environment.

  2. Clone the repository:

    git clone https://github.com/LichHunter/nixos

  3. Use Disko to install the minimal configuration for Fujin.

    nix run github:nix-community/disko#disko-install -- --flake .#fujin-minimal --disk main /dev/nvme0n1
  4. Reboot the machine.

Minimal System Setup

  1. Mount your backup drive:

    mkdir /tmp/drive; sudo mount /dev/sda1 /tmp/drive
  2. Copy the latest backup from the drive to your home folder.
  3. Unarchive the backup to restore essential files, including your SSH keys.

  4. Clone your NixOS repository using your SSH key:

    git clone git@github.com:LichHunter/nixos

  5. (Optional) Setup SSH for remote builds. Generate SSH key for root user to enable remote builds on izanagi:

    sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519

  6. (Optional) Add the root public key to izanagi configuration. First, get the public key:

    sudo cat /root/.ssh/id_ed25519.pub

    Then add this key to the openssh.authorizedKeys.keys section in machines/izanagi/default.nix and rebuild izanagi.

  7. Upgrade to the main configuration using the provided rebuild script. This script handles the full nixos-rebuild boot --flake .#fujin command, including sudo and build host settings.

    ./bin/rebuild.sh boot

  8. Install Emacs:

    git clone --depth 1 https://github.com/doomemacs/doomemacs ~/.config/emacs
~/.config/emacs/bin/doom install

  9. Copy your custom Doom Emacs configs:

    cp -r ~/nixos/machines/fujin/main/doom-configs/* ~/.config/doom/

  10. Sync your Doom Emacs configuration:

    ~/.config/emacs/bin/doom sync

Proxmox Installation Methods

Method 1: Remote Installation with nixos-anywhere

This method involves booting a minimal NixOS ISO on the target VM and then "pushing" the full configuration to it remotely.

Prerequisites

The minimal NixOS installation ISO does not have a default password for the root user. The nixos-anywhere command requires SSH access, which necessitates a password.

  1. Boot the Proxmox VM using the minimal NixOS installation ISO.
  2. Open a terminal on the VM's console.

  3. Set a password for the root user by running the following command:

    passwd

Deploying NixOS

With the root password set on the target VM, run nixos-anywhere from your local machine to deploy your NixOS configuration.

nix run github:nix-community/nixos-anywhere -- \
  --flake .#susano-minimal \
  --target-host root@192.168.1.85

After this step, proceed to the Post-Installation: Secrets Management section.

Method 2: Deployment via Proxmox Image Template

This method involves building a complete Proxmox backup file (.vma.zst) directly with Nix. This image can then be restored in Proxmox to create a new VM or a reusable template. This approach is faster for creating multiple machines.

Step 1: Build the Proxmox Image

Build the image using a dedicated flake output. This will produce a compressed Proxmox backup file in the ./result/ directory.

nix build .#izanami-proxmox

Step 2: Copy Image to Proxmox Host

You must copy the image to the directory Proxmox uses for backups. First, find this location by running the following command on your Proxmox host:

cat /etc/pve/storage.cfg

Look for a storage location (like dir: local) that includes backup in its content list. The path for that storage (e.g., /var/lib/vz) is the destination. Backups are typically stored in a dump subdirectory within that path.

Use scp to copy the generated .vma.zst file to the backup directory.

scp result/vzdump-*.vma.zst root@192.168.1.53:/var/lib/vz/dump/

Step 3: Restore Image from Proxmox UI

  1. Navigate to your Proxmox web UI.
  2. Select your backup storage location from the left-hand menu.
  3. Go to the Backups tab, select the newly uploaded image, and click the Restore button.
  4. Important: In the restore dialog, ensure the Unique checkbox is enabled. This generates a new MAC address and other unique identifiers for the restored VM.

Step 4: Test and Convert to Template

  1. (Recommended) Before creating a template, test the restored VM. Create a full clone of it, start the clone, and verify you can access it as expected (e.g., via SSH with the pre-configured user).

    ssh izanami@some_ip
  2. Once confirmed, you can convert the original restored VM into a template for easy reuse. Right-click the VM and select Convert to template.

Post-Installation: Secrets Management

(This section is primarily for Method 1, or for when a new host key needs to be added after using Method 2)

Step 1: Generating the Host AGE Key

After the installation is complete, you will need the host's AGE key to manage secrets with tools like sops-nix.

  1. SSH into the newly installed NixOS machine.

    ssh root@192.168.1.85

  2. Run the following command to convert the host's public SSH key to an AGE key.

    nix-shell -p ssh-to-age --run 'cat /etc/ssh/ssh_host_ed25519_key.pub | ssh-to-age'
  3. Copy the output AGE key for the next step.

Step 2: Updating SOPS and Re-encrypting Secrets

The new AGE key must be added to your .sops.yaml file.

  1. Open the .sops.yaml file in the root of your Nix flake.

  2. Replace the old key for the host with the new key you generated.

    keys:
  - &primary age19wvqtn4ju6k4vs8fxr34unl6xx4cv04jw0lx9ps20xlde927zfssgl4qke
  - &susano age1vkfq9gpqfpyq3s9e79e6vw8kv9485tzna4fm3dy6p0u9uz9feu8qr9sgcf # <--- REPLACE THIS WITH THE NEW KEY
creation_rules:
  - path_regex: secrets/secrets.yaml$
    key_groups:
      - age:
          - *primary
          - *susano

  3. After saving, run the updatekeys command to re-encrypt the secrets file with the new set of keys.

    sops updatekeys secrets/secrets.yaml

Available Utility Scripts

This repository includes several utility scripts in the bin/ directory to simplify common tasks.

rebuild.sh - Enhanced NixOS Rebuild Wrapper

A powerful wrapper around nixos-rebuild that provides intelligent defaults and simplified syntax for various deployment scenarios.

Features

  • Smart defaults for build hosts and machine configurations
  • Automatic sudo handling for local vs remote operations
  • Support for remote builds and deployments
  • Dry-run capabilities for testing changes
  • Comprehensive help and error messages

Basic Usage 

# Local build and switch (uses local machine)
./bin/rebuild.sh switch --local-build

# Remote build, local deployment (default behavior)
./bin/rebuild.sh switch

# Build only, no deployment
./bin/rebuild.sh build

Remote Operations 

# Deploy to remote machine (auto-detects machine name from hostname)
./bin/rebuild.sh switch --target-host user@remote-host

# Build on izanagi, deploy to susano
./bin/rebuild.sh switch --machine susano --target-host susano@susano

# Build on specific host, deploy to another
./bin/rebuild.sh switch --build-host builder@build-host --target-host user@target-host

Advanced Examples 

# Test configuration without making it permanent
./bin/rebuild.sh test --target-host susano@susano

# Dry run to see what would be built/changed
./bin/rebuild.sh switch --dry-run --verbose

# Build specific machine with custom build host
./bin/rebuild.sh build --machine fujin --build-host powerful@workstation

# Fast remote deployment (skip building Nix)
./bin/rebuild.sh switch --target-host remote --fast

# Verbose output with detailed tracing
./bin/rebuild.sh build --verbose --show-trace

Command Reference

Commands
  • build - Build the configuration without deploying
  • test - Build and activate temporarily (reverts on reboot)
  • switch - Build and activate permanently
  • boot - Build and set as boot default (requires reboot)
Options
  • --local-build - Force building on local machine
  • --build-host HOST - Specify remote build host (default: izanagi@izanagi)
  • --target-host HOST - Deploy to remote target host
  • --machine NAME - Machine configuration name (auto-detected if not specified)
  • --use-remote-sudo - Use sudo on remote target (auto-enabled for switch/boot)
  • --fast - Skip building Nix (useful for remote builds)
  • --dry-run - Show what would happen without making changes
  • --verbose - Enable verbose output
  • --show-trace - Show detailed error traces

backup.sh - Automated Backup Script

Creates timestamped tar archives of important directories and files.

Usage 

# Create backup with current timestamp
./bin/backup.sh

What it backs up

  • ~/.gnupg - GPG keys and configuration
  • ~/.ssh - SSH keys and configuration
  • ~/Documents - Personal documents
  • ~/Pictures - Photos and images
  • ~/org - Org-mode files
  • ~/nixos-dotfiles - NixOS configuration repository
  • ~/nixos - Alternative NixOS configuration location
  • ~/hetzner-nixos - Hetzner-specific configurations
  • ~/.authinfo.gpg - Encrypted authentication information

Backup location

Backups are stored in ~/Backup/ with filenames like backup-YYYYMMDDHHMIN.tar.

hash-util.sh - File Hash Verification

Verifies file integrity using SHA256 checksums.

Usage 

# Verify a file against its expected hash
./bin/hash-util.sh --path /path/to/file --hash <expected-sha256-hash>

Examples 

# Verify downloaded ISO
./bin/hash-util.sh --path nixos.iso --hash a1b2c3d4e5f6...

# Check configuration file integrity
./bin/hash-util.sh --path configuration.nix --hash $(sha256sum configuration.nix | cut -d' ' -f1)

pve-build.sh - Disposable LXC Builder on Proxmox VE

Builds a NixOS configuration on a throwaway LXC container running on the Proxmox VE node, then activates the result on the requester (= the machine invoking the script, by default). Offloads the heavy compilation work from the requester to a disposable builder; the closure is shipped back over nix copy and activated locally.

The disposable is cloned from a NixOS LXC ostemplate (nixos-lxc flake output, proxmox-lxc format). The template is built locally and uploaded to PVE on first use, then reused.

Prerequisites

  • An SSH alias pve in ~/.ssh/config pointing at the PVE node (the script defers all connection details — HostName, User, Port, IdentityFile — to SSH config). Override with PVE_HOST or --pve-host if your alias differs.
  • The operator's pubkey must be in the adminKeys list in machines/builder/default.nix. The disposable's builder user trusts whatever keys are listed there.
  • The caller must resolve disposable hostnames (nixos-builder-<VMID>) — typically via dnsmasq or split-DNS that reads from PVE. The script never uses IPs for SSH.
  • jq on the caller (to parse pvesh JSON output).

Flow

  1. Ensure a NixOS LXC ostemplate exists on PVE; build .#nixos-lxc locally and scp it if missing.
  2. Clone a fresh container under a free VMID (scanning downward from 9999), start it, wait for SSH on its hostname.

  3. Build phase (runs as the calling user, no sudo):

    nixos-rebuild build --flake .#<requester> --build-host root@<ct-ip>

    builds the closure on the disposable and copies it back to the local Nix store.

  4. Activate phase (only for test / switch / boot; runs locally with sudo, no --build-host):

    sudo nixos-rebuild <cmd> --flake .#<requester>

    the closure is already local, so this only activates.

  5. Destroy the disposable (pct destroy --purge --force).

The build/activate split avoids needing the requester's root user to SSH to the disposable — only the calling user does.

Composite vs. step commands

Each stage can be invoked on its own, or chained via the composite commands:

Composite Stages chained Disposable on success
build deploy-image + start-builder + build-on left running
test deploy-image + start-builder + build-on + activate(test) left running
switch deploy-image + start-builder + build-on + activate(switch) + destroy-builder destroyed
boot deploy-image + start-builder + build-on + activate(boot) + destroy-builder destroyed
Step command Stage Effect
check-image 1 Read-only: exit 0 if a NixOS LXC ostemplate is on PVE, 1 if not.
deploy-image 1 Idempotent: build .#nixos-lxc locally + scp to PVE if missing.
update-image 1 Force: rebuild .#nixos-lxc and replace the ostemplate on PVE.
start-builder 2 deploy-image + clone a fresh CT + start.
build-on [VMID] 3 Build closure on an existing disposable.
=activate <test\ switch\ boot>= 4 Activate LOCALLY (closure must already be in the local store).
destroy-builder [VMID] 5 pct destroy --purge --force.
info [VMID] - List disposables, or show detail for one.

Stateless design

The script writes no state files. Each step discovers prior steps' artifacts dynamically from PVE:

  • Disposables are identified by hostname pattern nixos-builder-<VMID> (override via CT_HOSTNAME_PREFIX). When a step needs a target VMID and none is passed explicitly, it queries pvesh get /cluster/resources for LXC containers matching the prefix.

    Exactly one match
    used automatically.
    Zero matches
    the step errors out and points at create.
    Multiple matches
    the step errors out, lists the matches, and asks for an explicit VMID.
  • VMID allocation starts at 9999 and scans downward (configurable via --vmid-start / --vmid-floor) so disposables sit clearly above regular VM IDs.
  • The built closure lives in the caller's local Nix store; nixos-rebuild finds it naturally during activate, so no IPC between build-on and activate is needed.

Hostname-based SSH

All SSH to disposables targets their hostname (nixos-builder-<VMID>), never their IP. The caller's resolver must be able to look up PVE container hostnames — typically via dnsmasq or split-DNS that reads from PVE. The script never resolves IPs for SSH; get_ct_ip is used only for info display and diagnostic logging.

This makes the script safe to re-run, interrupt, or split across shell sessions — there is no latest-vmid file to drift out of sync with reality.

Basic Usage 

# Full happy path — build + activate susano permanently, auto-destroy CT.
pve-build switch --machine susano

# Step-by-step (each step discovers the prior step's artifacts from PVE):
pve-build deploy-image                 # build + upload the LXC ostemplate (no-op if present)
pve-build start-builder                # clones a fresh disposable CT
pve-build build-on                     # discovers the CT on PVE, builds on it
pve-build activate switch              # activates locally (no SSH)
pve-build destroy-builder              # discovers the CT on PVE, destroys it

# Rebuild the LXC image after editing machines/builder/default.nix.
pve-build update-image

# Read-only check (exit 0 if image is already on PVE, 1 otherwise).
pve-build check-image && echo ready || echo missing

# Operate on a specific CT (skips discovery — needed when multiple exist).
pve-build build-on 305

Advanced Examples 

# Build + activate temporarily without persisting to the bootloader.
pve-build test --machine fujin

# Use a non-default PVE node and a higher starting VMID.
pve-build switch --pve-host root@10.0.0.5 --vmid-start 9999

# Keep the disposable even after a successful switch (for inspection).
pve-build switch --keep

# List every disposable currently on PVE.
pve-build info

# Inspect a specific disposable in detail.
pve-build info 307

# Destroy a specific disposable by VMID.
pve-build destroy-builder 307

Command Reference

Composite commands
  • build - deploy-image + start-builder + build-on.
  • test - build + activate temporarily (reverts on reboot).
  • switch - build + activate permanently. Disposable destroyed on success.
  • boot - build + set as boot default. Disposable destroyed on success.
Step commands
  • check-image - Read-only: exit 0 if ostemplate is on PVE, 1 if missing.
  • deploy-image - Idempotent: build .#nixos-lxc locally + scp to PVE if missing.
  • update-image - Force rebuild + replace the ostemplate on PVE.
  • start-builder - deploy-image + clone a fresh CT + start.
  • build-on [VMID] - Build closure on an existing disposable (default: discovered).
  • activate <test|switch|boot> - Activate LOCALLY (closure must already be built).
  • destroy-builder [VMID] - pct destroy --purge --force (default: discovered).
  • info [VMID] - List disposables, or show detail for one.
Aliases

The old command names still work as aliases:

  • ensure-template → deploy-image
  • create → start-builder
Options
  • --machine NAME - Requester machine name (default: current hostname).
  • --pve-host HOST - PVE SSH alias or target (default: pve).
  • --pve-storage NAME - Ostemplate storage (default: local).
  • --rootfs-storage NAME - Rootfs storage (default: local-lvm).
  • --bridge NAME - Network bridge (default: vmbr0).
  • --vmid-start N - Highest VMID to consider (default: 9999); scanned downward.
  • --vmid-floor N - Lowest VMID to consider (default: 100).
  • --rootfs-gib N - Rootfs size in GiB (default: 20).
  • --keep - Keep the disposable even on successful switch / boot.
  • --show-trace , --verbose - Passed through to nixos-rebuild.
Environment

= PVE_HOST= , = PVE_STORAGE= , = PVE_ROOTFS_STORAGE= , = PVE_BRIDGE= , = VMID_START= , = VMID_FLOOR= , = BUILD_SSH_USER= , = CT_BOOT_TIMEOUT= , = CT_ROOTFS_GIB= .

Notes

  • Disposables are matched by hostname prefix (nixos-builder- by default). If you want a parallel run with multiple builders, pass explicit VMIDs to build-on / destroy-builder / info.
  • destroy-builder calls pct destroy <vmid> --purge --force, so it stops and removes a running container in one step.
  • To rebuild the LXC template after editing machines/builder/default.nix, remove the old tarball from root@<pve>:/var/lib/vz/template/cache/ — the script always picks the alphabetically last nixos-lxc-*.tar.xz it finds.

Optional NixOS Modules

Reverse Proxies

The following modules can be enabled to provide a reverse proxy.

Note: Previously, all reverse proxy modules were considered non-functional. Recent troubleshooting has provided a fix for Traefik, but the other modules may still have issues.

NGINX

The initial switch to this configuration may be slow as it waits for ACME to issue SSL certificates.

dov = {
  # Reverse Proxy
  reverse-proxy = {
    nginx.enable = true;
  };
};

Traefik 

dov = {
  # Reverse Proxy
  reverse-proxy = {
    traefik.enable = true;
  };
};
Troubleshooting Traefik ACME with DuckDNS
  • Context: Issues getting an ACME certificate from DuckDNS with Traefik.
  • Roadblock: The process was failing, but eventually succeeded.

  • Possible Solutions:

    • Setting disablePropagationCheck = true; for the DNS challenge.
    • Extending the delay for the DNS challenge.
  • Notes: It's unclear which specific option resolved the issue. The first time Traefik tries to get a certificate it might fail, and a restart of the service is needed. After some time, the Let's Encrypt certificate will be received.

Caddy 

dov = {
  # Reverse Proxy
  reverse-proxy = {
    caddy.enable = true;
  };
};

File Servers

copyparty

Provides a web-based file manager. For more information, see the official documentation.

dov = {
  file-server.copyparty.enable = true;
};

Dependency: For copyparty to function correctly in this configuration, it requires a Samba share to be mounted to the path /MEDIA. Therefore, the samba module must also be enabled:

dov = {
  samba.enable = true;
};

Search Engines

searxng

A privacy-respecting metasearch engine. For more information, see the NixOS Wiki page.

dov = {
  searxng.enable = true;
};

YubiKey

Provides PAM U2F authentication (touch YubiKey for login/sudo) and a seamless SSH agent backed by the YubiKey PIV applet.

dov = {
  yubikey.enable = true;
};

PAM U2F (login & sudo)

After enabling the module and rebuilding, enroll your YubiKey:

  1. Create the YubiKey config directory:

    mkdir -p ~/.config/Yubico

  2. Generate the U2F key mapping (touch YubiKey when prompted):

    nix-shell -p pam_u2f --run 'pamu2fcfg -u fujin' > ~/.config/Yubico/u2f_keys

    Nushell users: use out> instead of >:

    nix-shell -p pam_u2f --run 'pamu2fcfg -u fujin' out> ~/.config/Yubico/u2f_keys

  3. Add a backup YubiKey (optional):

    nix-shell -p pam_u2f --run 'pamu2fcfg -u fujin -n' >> ~/.config/Yubico/u2f_keys

  4. Rebuild and switch:

    sudo nixos-rebuild switch --flake .#fujin

  5. Test:

    sudo true  # should prompt to touch YubiKey

The default mode is sufficient (touch key or type password). If the key is absent or not enrolled, the normal password prompt follows — you cannot lock yourself out.

SSH with FIDO2-backed keys

The module enables the standard OpenSSH agent (not GPG agent's SSH emulation, which doesn't reliably support -sk keys). The YubiKey uses FIDO2 — the same interface that PAM U2F uses — so no PIV/pcscd setup is needed for SSH.

  1. Generate a FIDO2-backed SSH key (one-time, touch YubiKey when prompted):

    ssh-keygen -t ed25519-sk -C "yubikey@fujin"

    Resident key (recoverable on a new machine without the stub file):

    ssh-keygen -t ed25519-sk -O resident -C "yubikey@fujin"

  2. Load the key into the agent (once per login session, enter passphrase):

    ssh-add ~/.ssh/id_ed25519_sk

    After a rebuild, log out and back in so the shell picks up the new SSH_AUTH_SOCK. In an existing session:

    export SSH_AUTH_SOCK=/run/user/$(id -u)/ssh-agent

  3. Copy the public key to remote hosts:

    ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub susano

  4. Test:

    ssh susano  # touch YubiKey, no password

Each SSH authentication requires a physical YubiKey touch. The passphrase is only asked when loading the key into the agent (step 2), not per-connection.

Note: The key stub (~/.ssh/id_ed25519_sk) is tied to this specific generation — regenerating produces a different key. Back it up or use -O resident.

Notes and Configuration Details

Remote Build Configuration

To leverage remote builds (e.g., building fujin configurations on izanagi), you need to set up SSH keys for the root user:

  1. On the machine that will initiate builds (e.g., fujin), generate SSH keys for root:

    sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519

  2. Add the root public key to the build host's (e.g., izanagi) authorized keys in the NixOS configuration:

    users.users.${username} = {
  openssh.authorizedKeys.keys = [
    "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBcGhVpjmWEw1GEw0y/ysJPa2v3+u/Rt/iES/Se2huH2 alexander0derevianko@gmail.com"
    "ssh-ed25519 AAAA... root@fujin"  # Add the new root key here
  ];
};

  3. The ./bin/rebuild.sh script is configured to use remote builds by default. To use local builds instead, use the --local-build flag:

    ./bin/rebuild.sh switch --local-build

Disko Configuration for Proxmox (MBR Boot)

A critical requirement for ensuring a NixOS VM can boot correctly in Proxmox is the disk partition scheme. Proxmox expects a Master Boot Record (MBR) compatible setup.

When using disko for declarative disk management, you must configure it to create a GPT partition table that includes a special 1M BIOS boot partition (type EF02). This partition is specifically used by GRUB for MBR compatibility.

Here is an example snippet for the disko configuration:

{
  disko.devices = {
    disk = {
      main = {
        device = "/dev/sda";
        type = "disk";
        content = {
          type = "gpt";
          partitions = {
            boot = {
              size = "1M";
              type = "EF02"; # for grub MBR
            };
            # ... your other partitions like root, swap, etc.
          };
        };
      };
    };
  };
}

For a complete example, you can refer to the official disko repository: gpt-bios-compat.nix.

Generating Hardware Configuration

The nixos-anywhere tool can automatically generate a hardware configuration file from the target machine. This is useful for capturing machine-specific settings.

nix run github:nix-community/nixos-anywhere -- \
  --flake .#your-flake-output \
  --target-host root@192.168.1.85 \
  --generate-hardware-config ./hardware-configuration.nix

TODOs

  • Update izanagi to include git by default.
  • Add NetworkManager to the fujin-minimal configuration.
  • Investigate and fix remaining issues with reverse proxy modules (NGINX, Caddy).
  • Troubleshoot and fix an issue that occurs when reloading the NixOS configuration remotely, which breaks the SSH pipe and requires entering the root password three times. Seems like this can be fixed if we allow remote user, for example 'fujin', to execute switch without sudo, but claude gave strange code to implement this. Will need to look into it some time later
  • Investigate and resolve the issue where updating a user's password declaratively using a secret managed by sops failed after the initial installation.
  • Refactor the disko configuration to make the disk device name (e.g., /dev/sda) a variable. This will avoid hardcoding the value and make the configuration more portable. You can provide drive name when installing with disko and then update disko-config. Example of install command 
    nix run github:nix-community/disko#disko-install -- --flake .#fujin-minimal --disk main /dev/nvme0n1
  • Create a custom ISO image to streamline the installation process, potentially pre-configuring items like the root user to avoid manual console steps. Now you can build izanami iso to for it. Use 
    nix build .#izanami-iso
  • Develop an automated installation script to handle the post-install process, such as fetching the AGE key and updating sops, based on this guide.
  • Document remote build setup process and add automation for SSH key exchange between machines. There is now rebuild.sh script that can be used for easy remote build
  • Add prometheus for services on Proxmox
  • Add matrix service in Proxmox

Inspiration

The configuration and structure of this setup were inspired by the following repository:

Links

Reference in New Issue View Git Blame Copy Permalink
S
Description
No description provided
Readme 529 KiB
Languages
Nix 64.8%
Shell 24%
Emacs Lisp 11.2%