About me: My name is Solène Rapenne, pronouns she/her. I like learning and sharing knowledge. Hobbies: '(BSD OpenBSD Qubes OS Lisp cmdline gaming security QubesOS internet-stuff). I love percent and lambda characters. OpenBSD developer solene@. No AI is involved in this blog.

Contact me: solene at dataswamp dot org or @solene@bsd.network (mastodon).

I'm a freelance OpenBSD, FreeBSD, Linux and Qubes OS consultant, this includes DevOps, DevSecOps, technical writing or documentation work.

If you enjoy this blog, you can sponsor my open source work financially so I can write this blog and contribute to Free Software as my daily job.

Managing a fleet of NixOS Part 3 - Welcome to Bento

Written by Solène, on 04 September 2022.
Tags: #bento #nixos #nix

Comments on Fediverse/Mastodon

1. Introducing Bento 🥳 §

I finally wrote an implementation for the NixOS fleet management, it's called Bento.

Bento git project repository

2. Features §

  • secure 🛡️: each client can only access its own configuration files (ssh authentication + sftp chroot)
  • efficient 🏂🏾: configurations can be built on the central management server to serve binary packages if it is used as a substituters by the clients
  • organized 💼: system administrators have all configurations files in one repository to easy management
  • peace of mind 🧘🏿: configurations validity can be verified locally by system administrators
  • smart 💡: secrets (arbitrary files) can (soon) be deployed without storing them in the nix store
  • robustness in mind 🦾: clients just need to connect to a remote ssh, there are many ways to bypass firewalls (corkscrew, VPN, Tor hidden service, I2P, ...)
  • extensible 🧰 🪡: you can change every component, if you prefer using GitHub repositories to fetch configuration files instead of a remote sftp server, you can change it
  • for all NixOS 💻🏭📱: it can be used for remote workstations, smartphones running NixoS, servers in a datacenter

3. Evolutions §

The project is still bare right now, I started it yesterday and I have many ideas to improve it:

  • package it to provide commands in $PATH instead of adding scripts to your config repository
  • add a rollback features in case an upgrade is losing connectivity
  • upgrades can depose a log file in the remote sftp server
  • upgrades could be triggered by the user by accessing a local socket, like opening a web page in a web browser to trigger it, if it returns output that'd be better
  • provide more useful modules in the utility nix file (automatically use the host as a binary cache for instance)
  • have a local information how to ssh to the client to ease the rebuild trigger (like a SSH file containing ssh command line)
  • a way to tell a client (when using flakes) to try to update flakes every time even if no configuration changed, to keep them up to date