Terracrypt

How I manage my Guix System configs

2026-02-15T13:41:00Z

I've been meaning to write up a post on how I manage my Guix System configurations for a while, because I've hit on a solution that feels kinda nice, inspired by how folks do things in NixOS.

In the NixOS world, there's a tool called nixos-generate-config that automatically creates both a configuration.nix and a hardware-configuration.nix for you. The idea is that the hardware-specific bits (like your partition layout, initrd modules, and such) go into hardware-configuration.nix, and the rest of your configuration goes into configuration.nix. We don't have an equivalent of nixos-generate-config in the Guix world to help automate this, but the general pattern seemed pretty nice, so I've roughly replicated it for my Guix config.

It ends up feeling a little messier in Guix than in Nix, because of some differences in how we build up our configs. But it's not too bad. There's a couple different layers here, so let's start with my config.scm for one of my machines. I'm omitting a few things for brevity but you can see the full file contents here if you're curious.

(define-module (system machines wired config)
  ...
  #:use-module (system machines wired hardware-configuration))

(define-public wired-operating-system
  (operating-system
   (inherit hardware-configuration)
   (locale "en_US.utf8")
   (timezone "America/New_York")
   (host-name "wired")
   (users
    (cons*
     (user-account
       ...)
     (operating-system-users hardware-configuration)))
   (packages
    (append
     (list luanti-server
           minetest-game
           ...)
     (operating-system-packages hardware-configuration)))))

This defines the operating-system that you would actually use in, for example, a guix system reconfigure. A few things to note about this:

We're inheriting a lot of this config from something called hardware-configuration, defined elsewhere.
In a few cases (users and packages), we're extending things that were defined in hardware-configuration. One of the things I use this machine for is hosting a Luanti server, so I need Luanti installed on it - but of course that's not something I need on all my servers! If you can't already tell from this, hardware-configuration is itself an operating-system record, so we can pull out each of its fields via procedures like operating-system-packages. If I just defined the list of packages in this file and didn't append to the packages from hardware-configuration, I would overwrite the list - which isn't what I want, since I have a base set of packages elsewhere that I'd like to keep.

Okay, let's take a look at hardware-configuration:

(define-module (system machines wired hardware-configuration)
  #:use-module (gnu)
  #:use-module (nongnu packages linux)
  #:use-module (system machines server-base))

(define-public hardware-configuration
  (operating-system
   (inherit jfred-server-base-system)
   (kernel linux)
   (firmware (list linux-firmware))
   (keyboard-layout (keyboard-layout "us"))

   (bootloader (bootloader-configuration
                (bootloader grub-efi-bootloader)
                (targets (list "/boot/efi"))
                (keyboard-layout keyboard-layout)))

   (mapped-devices (list (mapped-device
                          (source (uuid
                                   "a1775b70-cfc4-44d5-9fc3-0ddaff9eb694"))
                          (target "cryptroot")
                          (type luks-device-mapping))))

   (file-systems (cons* (file-system
                         (mount-point "/boot/efi")
                         (device (uuid "AF86-B19B"
                                       'fat32))
                         (type "vfat"))
                       (file-system
                         (mount-point "/")
                         (device "/dev/mapper/cryptroot")
                         (type "ext4")
                         (dependencies mapped-devices)) %base-file-systems))

   (host-name #f)))

This is where all my disk layout stuff lives, and it's where I keep any hardware-specific quirks. For example, this machine is an Intel NUC, so I need some proprietary firmware for all the hardware to work properly. So I use linux-firmware and the linux kernel from Nonguix here.

How exactly to split up the config between files is a bit of a judgement call, because not everything feels like it cleanly falls into one camp or the other. I moved things around a few times as I was putting this together.

You might have also noticed that the hardware-configuration itself inherits from another config (jfred-server-base-system). Yeah, I have multiple layers of inheritance here! Here's that definition:

(define-module (system machines server-base)
  ...
  #:use-module (system machines base))

(define-public jfred-server-base-system
  (operating-system
   ;; Set these in hardware-configuration.scm
   (bootloader #f)
   (host-name #f)
   (file-systems #f)
   (sudoers-file
     (plain-file "sudoers"
                 (string-append (plain-file-content %sudoers-specification)
                                (format #f "~a ALL = NOPASSWD: ALL~%"
                                        "jfred"))))

   ;; Base configs for my servers
   (locale "en_US.utf8")
   (keyboard-layout (keyboard-layout "us"))
   (timezone "America/New_York")
   (users (cons* (user-account
                  (name "jfred")
                  (comment "Jonathan Frederickson")
                  (group "users")
                  (home-directory "/home/jfred")
                  (supplementary-groups '("wheel" "netdev" "audio" "video")))
                 %base-user-accounts))
   (packages %base-packages)

   (services
   (append (list
            (service openssh-service-type
                     (openssh-configuration
                      (use-pam? #f)))
            (service elogind-service-type)
            (service dhcpcd-service-type)
            (service dbus-root-service-type)
            (service docker-service-type)
            (service containerd-service-type)
            (service ntp-service-type))
           (jfred-append-base-services %base-services)))))

This is where I keep configuration that should apply to all of my servers, rather than just one. I always want to have a user for myself in sudoers on each of them, for it to be in my local timezone, and for it to have the us keyboard layout. And there's a base set of services that I'll almost certainly want on any server I'm running.

This is the part of my config that feels the messiest to me. You might notice the fields set to #f at the top there; that's because it's an error to have an operating-system record that does not define all the fields. I'll always need to set the bootloader, filesystems, and hostname for any new machine anyway, so in practice it's not an issue - it just feels a bit weird.

And yes, there's yet another layer of composition with jfred-append-base-services at the end there. But I think this is where I'm going to stop. :)

I hope this post is helpful to someone in the future! And if you have any other ideas, I'd love to hear about them.

Brainstorming - managing a fleet of Guix machines with Goblins

2024-12-19T17:04:00Z

I've been noodling on the possibility of managing a bunch of Guix machines with Goblins for a little while now. Spent a little time at a local coffee shop today thinking about how this might work...

With both Guix and Goblins being written in Guile, it's at least pretty straightforward to start mashing them up:

(use-modules
 (goblins)
 (goblins actor-lib methods)
 (guix describe))

(define (^guix-machine-mgr bcom)
  (methods
   [(get-channels)
    (current-channels)]))

Of course, functions like current-channels return Guix records...

goblins/0@(guile-user) [1]> ($ mgr 'get-channels)
$6 = (#<<channel> name: guix url: "https://git.savannah.gnu.org/git/guix.git" branch: "master" commit: "5ab3c4c1e43ebb637551223791db0ea3519986e1" introduction: #<<channel-introduction> first-signed-commit: "9edb3f66fd807b096b48283debdcddccfea34bad" first-commit-signer: #vu8(187 176 45 223 44 234 246 168 13 29 230 67 162 160 109 242 163 58 84 250)> location: ((filename . "guix/channels.scm") (line . 1069) (column . 5))>)

...and I don't know yet whether these can be sent over a captp connection as-is or if I'll need to wrap them somehow. Gotta play around I guess!

One of the other things I haven't decided on yet is which parts of a Guix system exactly this should manage, since Guix lets multiple users have multiple profiles, and since the currently configured channels for a given user don't necessarily reflect the currently installed packages in the user's profile. It might make sense for such a Goblins daemon to take a specific profile as a parameter, and to essentially take ownership of that profile.

I'd also like it to be able to remotely manage the operating-system config and by extension the packages/services installed through it, though I'll need to figure out how exactly to do that. switch-to-system in (guix scripts system reconfigure) seems like it might be the right starting point.

My current (very rough) thought on what the management flow would look like is:

On a centralized management machine, have an object per client machine that represents the desired state of that machine, with a reference to the following daemon
On each client machine, have a daemon running that's managing the operating-system config on that machine, with a reference to the above object
When an admin updates the list of packages/services on the machine object, it sends a message to the client daemon prompting it to run a system rebuild
Periodically, the client daemon reaches out to the machine object to determine if it is up to date (e.g. if it's missed one of the above messages), and to fetch the current desired config if not

Visual structural editing for Guix (and Schemes in general)

2024-09-21T10:38:00Z

I've been noodling on structural editing for a while now. I'm fully bought into Lisps myself, but most of my friends and coworkers are skeptical, and I think a lot of their skepticism has to do (as usual) with all the parens. One of the points I make frequently is that with Lisp code being written as a nested data structure, the textual representation is just one of many possible representations. But it can be hard to get across what that means without concrete examples.

A few years back, I ran across Fructure for Racket. To this day, it's still the structural editor with the most appealing visual display to me. But Fructure itself has a few drawbacks for my purposes:

It's specifically targeting Racket. Racket is a wonderful Scheme, but I'm a Guix and Goblins user as well, and I would ideally like whichever editor I use to work with any Scheme, not just one.
It was a prototype, and its creator has mostly moved onto other projects.

In addition to these, I've been wanting a way to make Guix configuration as easy and painless as possible for new users. Having a sort of "command palette" available seems like it might be a good way to accomplish this.

So recently, I did a quick initial sketch of what such a system might look like:

I have a few initial use cases in mind:

Guix configuration, as particularly mentioned. Guix data structures (like operating-system or file-system) are written as Guix-specific record types, so there may be some metadata about expected values in each embedded in them that you can tap into somehow.
Content-addressed interfaces from the Spritely folks. This can make it more clear which methods are available to use on a remote Goblins object, and tying that into a visual command palette seems like it could be very nice.

Obviously given the fact that there are two styles of very different interfaces here, this has to involve some sort of runtime checking. And we probably can't entirely infer which to use based solely on the source code, so there's probably some per-project editor configuration needed for this to work. But... I think this might be doable.

I need to look into this some more, but a good starting point might be the nREPL protocol. It seems pretty extensible, and already has support for symbol lookups and such. But need to look into this all some more!