Title: Managing a fleet of NixOS Part 3 - Welcome to Bento | |
Author: Solène | |
Date: 04 September 2022 | |
Tags: bento nixos nix | |
Description: In this series of articles, I'll explain my steps toward | |
designing an infrastructure to centrally manage a fleet of NixOS | |
systems. The product is now alive and is called Bento. | |
# Introducing Bento 🥳 | |
I finally wrote an implementation for the NixOS fleet management, it's | |
called Bento. | |
Bento git project repository | |
# 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 | |
# 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 |