Skip to content

Nix/NixOS

The Skynet Cluster is (for the most part) running on a Linux variant called NixOS.
This article aims to introduce you to Nix and Nixos in order to get you up to speed to administer the cluster.

What it is

Nix

Package Manager

The word Nix refers to two things: a language and a package manager.
These are deeply interlinked together with the language being how the package manager is able to do its job.
Nix grew out of a PhD by Eelco Dolstra wherein he proposes a slightly different way to manage dependencies on a system.

For most Linux systems programs make use of other software installed on the computer, for the most part this works fine.
Where issue may arise is if one program needs to update one of these dependencies, specifically a minor or major patch where backwards compatibility is not guaranteed.
If another program is using this (system-wide) dependency then it may run into interface issues when using it.
In a sense updating one program can break another on the system.

The route the Nix package manager takes is it treats each program as a function.
Using the Nix language a function for that package is created which states what inputs are required, what is needed to turn those inputs into the program as well as the name for the output.
The output is then saved in a read only location in the format of /nix/store/$hash-program-name-version.
This output can either be used as the input of another program or be used as is by the system/user.
Using this format means that any change in the inputs or the program itself will result in a different output.
This means that multiple versions of the program (some even the same version but different commit) can co-exist on the one system.
An example using different versions of Firefox:
img.png

Example

An example of packaging an application can be found here:
Sieve Editor GUI on Nixpkgs

This is packaging up a GUI node.js application.
The application itself allows the user to edit sieve scripts.
Once you have downloaded and installed Nix you will be able to install and run it like so: 

nix-shell -p sieve-editor-gui
sieve-editor-gui .

Language

There are two partially difficult problems in computer science:

  1. Off-by-one errors
  2. Caching
  3. Naming things

Nix falls into this last pitfall.
The programming language used by the Nix package manager is called Nix, not NixLang (as like Erlang) but rather the same name as primary tool that uses it.
For clarity for the remainder of this subsection we are only talking about Nix the language.
The Nix Package manager is sometimes known as CppNix for reasons we will get into later.

Nix is a lazily evaluated functional language which also has REPL (Read, Evaluate, Print, and Loop) capability like what you would see in Python.
As a whole it takes strong influences from OCaml and other ML derived languages.

Types

It has most of the normal types that you would expect of a programming language, along with a few extra to deal with the filesystem: 

a = 1              # int
b = 1.001          # float
c = /path/to/thing # path
d = "42"           # string
e = true           # boolean

Of these the path type will be new to most people.
This can take either an absolute or relative path.

Functions

If you look at the section below it will seem that these are another type of assignment to a variable.
That is half right, these are akin to function pointers that you would see in C or C++.
Functions in Nix do not have types for either parameters or return.
This is due to it being lazily evaluated, like Python or Javascript.
As such the double function will accept any numeric value

double = x: x*2
mul = a: b: a*b

double 2
double 4.2
mul 7 6
Attribute Sets

In most languages the way to group data would be either an Object or a Struct.
Nix has a similar data structure:

s = { foo = "bar"; biz = "baz"; }
s.foo # bar
s.biz # baz
More data

This is a rough quickstart introduction to Nix.
For more detailed information I recommend these resources.

Flakes

A Flake is one of the best ways of interacting with nix.
Despite it having some issues and still being marked as experimental it has become a de-facto standard.
This is also the format that we use in Skynet.

The Official Wiki Page will be more informative than what can be shoved into this article.

Nixos

With the package manager we are able to create packages in a deterministic manner and store them in a way that does not suffer path conflicts.

Some (possibly crazy) folks saw this and decided to apply this to an entire operating system.
The advantages are clear, the required programs are added to the path for the current iteration of the system.
If any error arises the system can be rolled back to a previous config.

Configuration is done via *.nix files, which are then converted into the native config for the application in question.

For example this file turns a list of attributes. 

{
    record = "forgejo";
    r_type = "CNAME";
    value = "glados.skynet.ie";
}

Into a config usable by the BIND DNS server.

Lix

Nix is an old enough project now, and as such has accumulated crust over the years.
This is a combination of technical and societal/governance.

On the technical side nix is built using c++ and a max of build systems that make it hard to expand it.
For a good long time the nix binary used in the package manager was locked at v2.18 due to issues.
It took most of a year for a higher version to be used on an official basis.

Regarding governance there has been several attempts to make it better for folks to contribute and to decouple everything from requiring Eelco to have an input.
Those attempts did not succeed.
The final straw for some of the more technical core contributors was Eelco's forming a company, hiding it from the community and trying to get military sponsorship.
This did not vibe well with folks.

Due to all of this many core maintainers forked Nix at 2.18 and started working to apply fixes for both code and organisational.
The result of their efforts is Lix.
For a full explanation of its key features I would like to point you to the Lix About page.
We use Lix instead of CppNix as the goals of Lix align with the viewpoints and ideologies that our members hold and what we want to represent as a (computer) society.

Why we use it

Back in January 2023 we got disconnected from the internet.
For the purposes of this document the root cause is not of importance. What is the mad Indian Jones treasure config hunt that it triggered.
Brendan delving for configs
Additionally, ITD require us to update our systems regularly (as they should be).
Technically this config delving is an ongoing effort, the old hard drives are occasionally connected up and raided.

As you would imagine this is not ideal, an exasperating factor was that many programs had changed both the location and format of their configuration over the decades that Skynet has been using them.

This is where the strengths of NixOS lie.
The config for the entire cluster is located in a singular location.
Using modules which work as a translation layer if the requirements for the programs change this don't impact us.
Not to mention we can fearlessly (and regularly) update our systems it is a match made is heaven.

Currently, the Skynet cluster comprises 15 servers which have NixOS on them.
A combination of LXC's (Linux Containers) and physical bare metal servers.
Since these systems share a base config (with their individual applications layered on top) we are able to efficiently build them, building a package for one will also build it for other servers.
Combine that with the ability to deploy them via our own self-hosted CI/CD we have a strong foundation to work off of.

How we use it

Nix cannot run on Windows, though it cna be installed into WSL.
Please refer to the below downloads to get a base system up and running

  • Git
    • As we are using a git repo this is a hard requirement.
  • Git LFS
    • For storing non text files such as images.
  • Nix
    • Cant really use nix without thi installed.

Dev Shell

After cloning the repo use nix develop to set up a terminal shell with the environment for working with Skynet NixOS.
It (currently) adds Colmena, Agenix and Attic.

Another example of a dev shell can be our discord bot.
This one sets up a rust environment.

Of course, you can also look at the dev shell for this wiki.
For the wiki we need to ensure that the dependencies for building it are present for all users so they don't have to figure out how to manually install them.

Colmena

Colmena is our build and deployment tool.

Building is pretty easy, just run colmena build.
Downside of that command is it will try to build everything all at once which is a lot.
A more practical approach is to build a single server or a group of servers. 

# build the Skynet server, names can be found in the flake.nix
colmena build --on skynet

# build a group of servers, in this case any one with the tag of active-core
colmena build --on @active-core

To be able to deploy to Skynet two things are required:

  • Be on the UL network
    • This can also be accomplished by being on the VPN.
  • Have an ssh key configured that can access the servers
    • TLDR be an admin.

Agenix

Agenix is our secrets manager.
To be able to use this tool your pub ssh key must be in secrets/secrets.nix.
As you would expect this is an admin only tool.
This file also defines the names and permissions for each secret.

# have to be in the secrets folder for all these commands.
cd secrets

# edit the secret
agenix -e path/to/secret.age

# re-key all secrets, this is done when a new key is added or removed.
agenix -r

Attic

Attic is the tool that we use for our nix cache (hosted at ).
It is not often used by the developer/admin and its own documentation covers it best.