forked from Skynet/wiki
assignment: formatting and typos
This commit is contained in:
parent
029a181e7e
commit
fcac8c2448
GPG key ID:
36F93D61BAD3FD7D
2 changed files with 40 additions and 38 deletions
BIN
_git.tar.gz
(Stored with Git LFS)
BIN
_git.tar.gz
(Stored with Git LFS)
Binary file not shown.
|
|
@ -11,11 +11,11 @@ Nix grew out of a [PhD by Eelco Dolstra][nix_paper] wherein he proposes a slight
|
|||
|
||||
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, specially 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.
|
||||
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 teh Nix language a function for that package is created which states what inputs are required, what is needed to turn those inputs into teh program as well as the name for the output.
|
||||
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.
|
||||
|
|
@ -29,7 +29,7 @@ An example of packaging an application can be found here:
|
|||
|
||||
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](#download) Nix you will be able to install and run it like so:
|
||||
Once you have [downloaded and installed](#how-we-use-it) Nix you will be able to install and run it like so:
|
||||
```shell
|
||||
nix-shell -p sieve-editor-gui
|
||||
sieve-editor-gui .
|
||||
|
|
@ -37,13 +37,14 @@ sieve-editor-gui .
|
|||
|
||||
#### Language
|
||||
There are two partially difficult problems in computer science:
|
||||
1. Off by one errors
|
||||
2. Caching
|
||||
3. Naming things
|
||||
|
||||
1. Off-by-one errors
|
||||
2. Caching
|
||||
3. Naming things
|
||||
|
||||
Nix falls into this last pitfall.
|
||||
The programming language used by teh 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 teh remainder of this subsection we are only talking about Nix the language.
|
||||
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 al has REPL (Read, Evaluate, Print, and Loop) capability like what you would see in Python.
|
||||
|
|
@ -78,7 +79,7 @@ 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 datastructure:
|
||||
Nix has a similar data structure:
|
||||
```nix
|
||||
s = { foo = "bar"; biz = "baz"; }
|
||||
s.foo # bar
|
||||
|
|
@ -90,23 +91,23 @@ This is a rough quickstart introduction to Nix.
|
|||
For more detailed information I recommend these resources.
|
||||
|
||||
* [Official Guide][nix_guide_official]
|
||||
* [Nix Pills][nix_guide_pills]
|
||||
* [Nix Pills][nix_guide_pills]
|
||||
|
||||
### Flakes
|
||||
A Flake is one of teh best ways of interacting with nix.
|
||||
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][nix_flake] will be more informative than what can be shoved into this article.
|
||||
|
||||
### Nixos
|
||||
With teh package manager we are able to create packages in a deterministic manner and store them in a way that does not suffer path conflicts.
|
||||
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 teh path for teh current iteration of the 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 teh native config for the application in question.
|
||||
Configuration is done via ``*.nix`` files, which are then converted into the native config for the application in question.
|
||||
|
||||
For example [this file][nix_dns] turns a list of attributes.
|
||||
```nix
|
||||
|
|
@ -137,45 +138,45 @@ For a full explanation of its key features I would like to point you to the [Lix
|
|||
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 teh internet][skynet_disconnect].
|
||||
Back in [January 2023 we got disconnected from the internet][skynet_disconnect].
|
||||
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][skynet_disconnect_reenactment]
|
||||
Additionally ITD require us to update our systems regularly (as they should be).
|
||||
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, a 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.
|
||||
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 teh strengths of NixOS lie.
|
||||
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 dont impact us.
|
||||
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 is comprised of 15 servers which have NixOS on them.
|
||||
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 tehir individual applications layered on top) we are able to efficiently build them, building a package for one will also built it for other servers.
|
||||
Combine that with teh ability to deploy them via our own selfhosted CI/CD we have a strong foundation to work off of.
|
||||
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][git_git]
|
||||
* As we are using a git repo this is a hard requirement.
|
||||
* As we are using a git repo this is a hard requirement.
|
||||
* [Git LFS][git_lfs]
|
||||
* For storing non text files such as images.
|
||||
* For storing non text files such as images.
|
||||
* [Nix][nix_install]
|
||||
* Cant really use nix without thi installed.
|
||||
* 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][dev_colmena], [Agenix][dev_agenix] and [Attic][dev_attic].
|
||||
|
||||
Another example of a dev shell can be [our discord bot][dev_discord-bot].
|
||||
This one sets up a rust enviroment.
|
||||
This one sets up a rust environment.
|
||||
|
||||
Of course you can also look at the dev shell for this [wiki][dev_wiki].
|
||||
For the wiki we need to ensure that the dependencies for building it are present for all users so tehy dont have to figure out how to manually install them.
|
||||
Of course, you can also look at the dev shell for this [wiki][dev_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][dev_colmena] is our build and deployment tool.
|
||||
|
|
@ -184,18 +185,19 @@ 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.
|
||||
```shell
|
||||
# build the Skynet server, names cna be found in teh flake.nix
|
||||
# build the Skynet server, names cna be found in the flake.nix
|
||||
colmena build --on skynet
|
||||
|
||||
# build a group of servers, in this case any one with teh tag of active-core
|
||||
# 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 teh UL network
|
||||
* This can also be accomplished by being on the VPN.
|
||||
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.
|
||||
* TLDR be an admin.
|
||||
|
||||
### Agenix
|
||||
[Agenix][dev_agenix] is our secrets manager.
|
||||
|
|
@ -204,7 +206,7 @@ As you would expect this is an admin only tool.
|
|||
This file also defines the names and permissions for each secret.
|
||||
|
||||
```shell
|
||||
# have to be in teh secrets folder for all these commands.
|
||||
# have to be in the secrets folder for all these commands.
|
||||
cd secrets
|
||||
|
||||
# edit the secret
|
||||
|
|
@ -215,7 +217,7 @@ agenix -r
|
|||
```
|
||||
|
||||
### Attic
|
||||
[Attic][dev_attic] is teh tool that we use for our nix cache (hosted at <vhttps://nix-cache.skynet.ie/>).
|
||||
[Attic][dev_attic] is the tool that we use for our nix cache (hosted at <vhttps://nix-cache.skynet.ie/>).
|
||||
It is not often it is used by the dev and its own [documentation][dev_attic_docs] covers it best.
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue