Management protocol for NixOS desktop?

1

Hello,

I’m CTO of a MDM startup (bravas.io) looking to get more understanding of NixOS and its roadmap.

A MDM is a Mobile Device Manager, a solution here to help organization to manage a fleet of endpoint at scale.

By manage here you can understand:

  • enforce encryption and collect recovery key
  • distribute certificates from a PKI
  • install & configure apps

Currently we support iOS and macOS, and are working on the Windows support.

And of course, the next step is Linux support (in about a year). Which will be hard because so far, no management protocol seems to exist for Linux accros distributions.

This is how I’ve learned about NixOS and its vision.

So I’m curious about the future and a way for us to support NixOS as our first supported Linux.

Is a management protocol something already in mind for NixOS? If not, is it something that we could propose?

3 Likes
2

Is a management protocol something already in mind for NixOS?

What aspects would a management protocol cover in your eyes? NixOS is already a fully declarative system abstracting almost every single program configuration (including browser defaults and add-ons).

I think you would potentially hook into NixOS itself via nix-files/modules/overlays, give the user some way to allow configuration themselves and then remotely run some sort of nixos-rebuild switch to switch to a new configuration. The Nix configs can be sourced through https, git or nix files on the local filesystem. An MDM would likely just automate the part of distributing and applying nixos-rebuild.

Linux doesn’t has a “management protocol”, but that’s partially due to the fact that Linux configuration and software management has been much more coherent than on Windows/macos to some extend. In Linux world I would see “configuration management” the equivalent of a “management protocol”. Saltstack/puppet/ansible/purpleidea mgmt are all tools that allow managing of Linux environments remotely, many of the configuration modules are/can be implemented in an distribution agnostic way. I think the benefit with NixOS is that you get to have much tighter control and reproducibility/rollback mechanisms. With traditional config management tools, you always apply on top of an existing “state”, you often end up implementing transition states where you have to revert previous states, with NixOS such occurances are a minimum.

2 Likes
3

Management protocol has to be differentiated here from management payload and commands.

The payloads are the actually settings you want to enforce on the endpoint. Unlike windows and its register, or macOS with UserDefaults, Linux does not have a standard configuration database. It’s flat file, eventually in /etc, not necessarily in the same file format, and not with a single access process.

This is where the works in NixOS is really useful, it start to create a common process of configuration for all dependencies.

The commands are what you currently have via the CLI (apply the config change, etc)

The protocol however, is how you integrate an infinite number of endpoint with a centralized system.

The management protocol need to:

  • allow endpoint to report this situation change (disk usage, available update, etc)
  • distribute the commands and payload at scale (all managed devices enrolled for a user member of the group developers will get the configuration payload to install git)
  • allow enrollment in self service and during initial installation

If we look at how it works on other platforms (iOS, macOS, windows, and somehow Android, ChromeOS is different) this protocol is quite simple, allow some basic messaging and event handling, and let the whole logic up to the MDM implementation.

The server side is the MDM, and the client side is an MDM agent built into the system by the “vendor” of the OS for iOS, macOS, and windows. For ChromeOS, the MDM agent is built by the MDM vendor and use Android native API.

This is where the value could be in NixOS, having the nix toolset supporting a management server in addition to the local commands.

Somehow it’s like puppet/cheff/etc, except that when you are managing endpoint, it’s always behind firewall and NAT, so it needs to be outgoing communication from the endpoint to the management server. You cannot SSH into it.

1 Like
4

Thank you for elaborating further. I think the things you are listing are plain R&D efforts you have to come up with as a proprietary commercial provider. I agree with SSH not being the appropriate way. Puppet/Salt/mgmt are per design a pull based strategy, so already prepared for being behind Firewalls/NATs. There are a variety of tools in various extends that might already help you with the task.

If not, is it something that we could propose?

I think it’s certainly something you can propose, the community is certainly always excited about new ideas and influences. I believe currently the main focus for the community are exploring ways for NixOS deployment tools, which may or may not be covering what you might need or want.

I believe MDM by it’s nature has some different needs than just deploying tools, but perhaps some already are building some fundamental aspects one wants to build on. In the end it’s really a question of how you want to in-vision MDM altogether for NixOS users. I suppose you have like fully-managed, half-managed or partially-managed MDM systems. (like prohibiting any local system changes, managing just some fundamentals (provisioning/enforcing collecting data on some aspects), allowing some (like using flake nix for dev environments). Each of those are different audiences (Linux for regular web browser/media editing users, Linux for admins, Linux for developers) and implementing an MDM for Linux will highly depend on which user-group you will be able to target. I think in enterprise perspective, Linux is primarily used by developers and administrators, where they usually demand some sort of self-authority.

Note: I’m just a NixOS community newcomer myself, so take all my comments with a grain of salt :), I’m mostly interested in MDM topics since I spent some thoughts on that from professional jobs perspective. Linux world remains mostly unmanaged.

5

The management protocol of NixOS is an API to programmatically edit the configuration files and trigger rebuild switch, alternatively: to deploy the closure and switch into it.

Whether you rsync .nix and do a nixos-rebuild switch or you have the actual effective version of GitHub - RaitoBezarius/nixit: Code transformation tooling for Nix is up to you.

Note that unprivileged end users can always “install” applications as long as they don’t require root privileges (e.g. SUID bit), so I don’t really know if you want to prevent this in your model or not, if so, you will need to modify the Nix daemon itself.

With respect to a mgmt network protocol, I think we appreciate standards and not proprietary tooling, so maybe you could look into NETCONF and see if there’s any acceptable reasonable NETCONF standard that a NixOS system could itself adopt. But maybe you need a bespoke tooling.

Personally, I do things using osquery.

2 Likes
6

I do believe in open standards too. If we start to contribute on the management framework (and before that to the needed RFC) for NixOS, it clearly will be for FOSS mindset for the client side and protocol. And each MDM vendor is free to implement a server side the way it wants (or an open source MDM like micromdm could start to support NixOS too).

An open standard already exist for that, OMA-DM, but beside Microsoft I don’t know anyone using it. So maybe not a great idea to stick to it as it is an old protocol.

NETCONF is push also, it could be a evolution of it to be pull based, but would also need to add reporting capabilities (to react to a local change and report to the server).

Most management frameworks that currently existing are from 2000-2010. The learning in between are pushing people like Apple and Microsoft to review their protocol to adopt to the modern needs around it nowadays.

The fact that NixOS already have local API to interact with the configuration and to trigger the rebuild switch is interesting. It make it closer to the way Android behave.

Android unlike other platform does not have an mdmagent able to talk with a server, but a MDM framework that a custom made agent need to integrate with. Protocol with the server is up to the MDM vendor.

We could eventually imagine something equivalent for NixOS, even if I think an FOSS client would be more useful for the community.

1 Like
7

I feel like you know what to do :slight_smile:, feel free to ping the community if you have things to show and you would like our opinions!

1 Like
8

@ygi we’re considering NixOS as the OS for developers in our company but would require a functional MDM solution before committing, please keep us up to date with your Linux support! We would be open to beta-testing to help get NixOS support off the ground.

1 Like
9

It wont be for that year (except if someone help on the finance side).

But what we could start here is a proper RFC, to define an open protocol between NixOS and an MDM server.