Title: Managing a fleet of NixOS Part 3

	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