faukah/nichts
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

added stuff

Browse source
This commit is contained in:
vali 2024-04-09 23:11:33 +02:00
commit 7d4f626b7d
907 changed files with 70990 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

18
nyx/docs/notes/2023-01-22-system-backlight.md Normal file
View file

@ -0,0 +1,18 @@
# Notes for 22th of January, 2023
Following a system upgrade two days ago, my HP Pavillion laptop has stopped
registering the `intel_backlight` interface in `/sys/class/backlight`, which
is most often used to control backlight by tools such as `brightnessctl.`
Inspecting `dmesg` has given me nothing but aninsanely vague error message.
Only mentioning it is not being loaded (_very helpful, thanks!_)
After some research, on Google as every other confused Linux user, I have
come across [this article](https://www.linuxquestions.org/questions/slackware-14/brightness-keys-not-working-after-updating-to-kernel-version-6-a-4175720728/)
which mentions backlight behaviour has changed sometime after kernel 6.1.4.
Fortunately for me, the article also refers to the the ever so informative
ArchWiki, which instructs passing one of the [three kernel command-line options](https://wiki.archlinux.org/title/backlight#Kernel_command-line_options).
depending on our needs.
As I have upgraded from 6.1.3 to 6.1.6 with a flake update, the `acpi_backlight=none`
parameter has made it so that it would skip loading intel backlight entirely. Simply switching
this parameter to `acpi_backlight=native` as per the article above has fixed the issue.

355
nyx/docs/notes/2023-03-14-impermanence.md Normal file
View file

@ -0,0 +1,355 @@
# Notes for 14th of March, 2023
Today was the day I finally got to setting up both "erase your darlings"
and proper disk encryption. This general setup concept utilizes NixOS'
ability to boot off of a disk that contains only `/nix` and `/boot`, linking
appropriate devices and blocks during the boot process and deleting all state
that programs may have left over my system.
The end result, for me, was a fully encrypted that uses btrfs
snapshots to restore `/` to its original state on each boot.
## Resources
- [This discourse post](https://discourse.nixos.org/t/impermanence-vs-systemd-initrd-w-tpm-unlocking/25167)
- [This blog post](https://elis.nu/blog/2020/06/nixos-tmpfs-as-home)
- [This other blog post](https://guekka.github.io/nixos-server-1/)
- [And this post that the previous post is based on](https://mt-caret.github.io/blog/posts/2020-06-29-optin-state.html)
- [Impermanence](https://github.com/nix-community/impermanence)
## The actual set-up (and reproduction steps)
I've had to go through a few guides before I could figure out a set up that I
really like. The final decision was that I would have an encrypted disk that
restores itself to its former state during boot. Is it fast? Absolutely not.
But it sure as hell is cool. And stateless!
To return the root (and only the root) we use a systemd service that fires
shortly after the disk is encrypted but before the root is actually mounted.
That way, we can unlock the disk, restore the disk to its pristine state
using the snapshot we have taken during installation and mount the root to
go on with our day.
### Reproduction steps
#### Partitioning
First you want to format your disk. If you are really comfortable with
bringing parted to your pre-formatted disks, by all means feel free to skip
this section. I, however, choose to format a fresh disk.
Start by partitioning the sections of our disk (sda1, sda2 and sda3)
_Device names might change if you're using a nvme disk, i.e nvme0p1._
```bash
# Set the disk name to make it easier
DISK=/dev/sda # replace this with the name of the device you are using
# set up the boot partition
parted "$DISK" -- mklabel gpt
parted "$DISK" -- mkpart ESP fat32 1MiB 1GiB
parted "$DISK" -- set 1 boot on
mkfs.vfat -n BOOT "$DISK"1
```
```bash
# set up the swap partition
parted "$DISK" -- mkpart Swap linux-swap 1GiB 9GiB
mkswap -L SWAP "$DISK"2
swapon "$DISK"2
```
_I do in fact use swap in the civilized year of 2023[^1]. If I were a little
more advanced, and if I did not disable hibernation due to overly-hardened
kernel parameters, I would also be encrypting the swap to secure the hibernates...
but that is *currently* out of my scope. You may find this desirable, however, I
will not be providing instructions on that._
Encrypt your partition, and open it to make it available under `/dev/mapper/enc`.
```bash
cryptsetup --verify-passphrase -v luksFormat "$DISK"3 # /dev/sda3
cryptsetup open "$DISK"3 enc
```
Now partition the encrypted device block.
```bash
parted "$DISK" -- mkpart primary 9GiB 100%
mkfs.btrfs -L NIXOS /dev/mapper/enc
```
```bash
mount -t btrfs /dev/mapper/enc /mnt
# First we create the subvolumes, those may differ as per your preferences
btrfs subvolume create /mnt/root
btrfs subvolume create /mnt/home
btrfs subvolume create /mnt/nix
btrfs subvolume create /mnt/persist # some people may choose to put /persist in /mnt/nix, I am not one of those people.
btrfs subvolume create /mnt/log
```
Now that we have created the btrfs subvolumes, it is time for the _readonly_
snapshot of the root subvolume.
```bash
btrfs subvolume snapshot -r /mnt/root /mnt/root-blank
# Make sure to unmount, or nixos-rebuild will try to remove /mnt and fail
umount /mnt
```
#### Mounting
After the subvolumes are created, we mount them with the options that we want.
Ideally, on NixOS, you want the `noatime` option [^2] and zstd
compression, especially on your `/nix` partition.
The following is my partition layout. If you have created any other subvolumes
in the step above, you will also want to mount them here. Below setup assumes
that you have been following the steps as is.
```bash
# /
mount -o subvol=root,compress=zstd,noatime /dev/mapper/enc /mnt
# /home
mkdir /mnt/home
mount -o subvol=home,compress=zstd,noatime /dev/mapper/enc /mnt/home
# /nix
mkdir /mnt/nix
mount -o subvol=nix,compress=zstd,noatime /dev/mapper/enc /mnt/nix
# /persist
mkdir /mnt/persist
mount -o subvol=persist,compress=zstd,noatime /dev/mapper/enc /mnt/persist
# /var/log
mkdir -p /mnt/var/log
mount -o subvol=log,compress=zstd,noatime /dev/mapper/enc /mnt/var/log
# do not forget to mount the boot partition
mkdir /mnt/boot
mount "$DISK"1 /mnt/boot
```
And finally let NixOS generate the hardware configuration.
```bash
nixos-generate-config --root /mnt
```
The genereated configuration will be available at `/mnt/etc/nixos`.
Before we move on, we need to add the `neededForBoot = true;` to some mounted
subvolumes in `hardware-configuration.nix`. It will look something like this:
```nix
# Do not modify this file! It was generated by ‘nixos-generate-config’
# and may be overwritten by future invocations. Please make changes
# to /etc/nixos/configuration.nix instead.
{
config,
lib,
pkgs,
modulesPath,
...
}: {
imports = [
(modulesPath + "/installer/scan/not-detected.nix")
];
boot.initrd.availableKernelModules = ["xhci_pci" "ahci" "usb_storage" "sd_mod" "rtsx_pci_sdmmc"];
boot.initrd.kernelModules = [];
boot.kernelModules = ["kvm-intel"];
boot.extraModulePackages = [];
fileSystems."/" = {
device = "/dev/disk/by-uuid/b79d3c8b-d511-4d66-a5e0-641a75440ada";
fsType = "btrfs";
options = ["subvol=root"];
};
boot.initrd.luks.devices."enc".device = "/dev/disk/by-uuid/82144284-cf1d-4d65-9999-2e7cdc3c75d4";
fileSystems."/home" = {
device = "/dev/disk/by-uuid/b79d3c8b-d511-4d66-a5e0-641a75440ada";
fsType = "btrfs";
options = ["subvol=home"];
};
fileSystems."/nix" = {
device = "/dev/disk/by-uuid/b79d3c8b-d511-4d66-a5e0-641a75440ada";
fsType = "btrfs";
options = ["subvol=nix"];
};
fileSystems."/persist" = {
device = "/dev/disk/by-uuid/b79d3c8b-d511-4d66-a5e0-641a75440ada";
fsType = "btrfs";
options = ["subvol=persist"];
neededForBoot = true; # <- add this
};
fileSystems."/var/log" = {
device = "/dev/disk/by-uuid/b79d3c8b-d511-4d66-a5e0-641a75440ada";
fsType = "btrfs";
options = ["subvol=log"];
neededForBoot = true; # <- add this
};
fileSystems."/boot" = {
device = "/dev/disk/by-uuid/FDED-3BCF";
fsType = "vfat";
};
swapDevices = [
{device = "/dev/disk/by-uuid/0d1fc824-623b-4bb8-bf7b-63a3e657889d";}
# if you encrypt your swap, it'll also need to be configured here
];
nixpkgs.hostPlatform = lib.mkDefault "x86_64-linux";
powerManagement.cpuFreqGovernor = lib.mkDefault "powersave";
}
```
Do keep in mind that the NixOS hardware scanner **cannot** pick up your mount
options. Which means that you should specifiy the options (i.e `noatime`) for
each btrfs volume that you have created in `hardware-configuration.nix`. You
can simply add them in the `options = [ ]` list in quotation marks. I
recommend adding at least zstd compression, and optionally `noatime`.
### Closing Notes
And that should be all. By this point you are pretty much ready to install
with your existing config. I generally use my configuration flake to boot, so
there is no need to make any revisions. If you are starting from scratch, you
may consider tweaking your configuration.nix before you install the system.
An editor, such as Neovim, or your preferred DE/wm make good additions to your
configuration.
Once it's all done, take a deep breath and `nixos-install`. Once the
installation is done, you'll be prompted for the root password and after that
you can reboot. Now you are running NixOS on an encrypted disk. Nice!
Next up, if you are feeling _really_ fancy today, is to configure disk
erasure and impermanence.
#### Impermanence
For BTRFS snapshots, I use a systemd service that goes
```nix
boot.initrd.systemd = {
enable = true; # this enabled systemd support in stage1 - required for the below setup
services.rollback = {
description = "Rollback BTRFS root subvolume to a pristine state";
wantedBy = [
"initrd.target"
];
after = [
# LUKS/TPM process
"systemd-cryptsetup@enc.service"
];
before = [
"sysroot.mount"
];
unitConfig.DefaultDependencies = "no";
serviceConfig.Type = "oneshot";
script = ''
mkdir -p /mnt
# We first mount the btrfs root to /mnt
# so we can manipulate btrfs subvolumes.
mount -o subvol=/ /dev/mapper/enc /mnt
# While we're tempted to just delete /root and create
# a new snapshot from /root-blank, /root is already
# populated at this point with a number of subvolumes,
# which makes `btrfs subvolume delete` fail.
# So, we remove them first.
#
# /root contains subvolumes:
# - /root/var/lib/portables
# - /root/var/lib/machines
btrfs subvolume list -o /mnt/root |
cut -f9 -d' ' |
while read subvolume; do
echo "deleting /$subvolume subvolume..."
btrfs subvolume delete "/mnt/$subvolume"
done &&
echo "deleting /root subvolume..." &&
btrfs subvolume delete /mnt/root
echo "restoring blank /root subvolume..."
btrfs subvolume snapshot /mnt/root-blank /mnt/root
# Once we're done rolling back to a blank snapshot,
# we can unmount /mnt and continue on the boot process.
umount /mnt
'';
};
};
```
> You may opt in for `boot.initrd.postDeviceCommands = lib.mkBefore ''`
> as [this blog post](https://mt-caret.github.io/blog/posts/2020-06-29-optin-state.html)
> suggests. I am not exactly sure how exactly those options actually
> compare, however, a systemd service means it will be accessible through the
> the systemd service interface, which is why I opt-in for a service.
##### Implications
What this implies is that certain files such as saved networks for
network-manager will be deleted on each reboot. While a little clunky,
[Impermanence](https://github.com/nix-community/impermanence) is a great
solution to our problem.
Impermanence exposes to our system an `environment.persistence."<dirName>"` option that we can use to make certain directories or files permanent.
My module goes like this:
```nix
imports = [inputs.impermanence.nixosModules.impermanence]; # the import will be different if flakes are not enabled on your system
environment.persistence."/persist" = {
directories = [
"/etc/nixos"
"/etc/NetworkManager/system-connections"
"/etc/secureboot"
"/var/db/sudo"
];
files = [
"/etc/machine-id"
# ssh stuff
"/etc/ssh/ssh_host_ed25519_key"
"/etc/ssh/ssh_host_ed25519_key.pub"
"/etc/ssh/ssh_host_rsa_key"
"/etc/ssh/ssh_host_rsa_key.pub"
# if you use docker or LXD, also persist their directories
];
};
```
And that is pretty much it. If everything went well, you should now be telling
your friends about your new system boasting full disk encryption _and_ root
rollbacks.
## Why?
Honestly, why not?
[^1]:
I could be using `tmpfs` for `/` at this point in time. Unfortunately, since I share this setup on some of my low-end laptops, I've got no RAM
to spare - which is exactly why I have opted out with BTRFS. It is a reliable filesystem that I am used to, and it allows for us to use a script
that we'll see later on.
[^2]: https://opensource.com/article/20/6/linux-noatime

145
nyx/docs/notes/2023-05-21-packaging-nextjs-webapps.md Normal file
View file

@ -0,0 +1,145 @@
# Notes for 21st of June, 2023
Recenty I have had to go through the misfortune of hosting some websites
written with _NextJS_ on my VPS running NixOS, this note entry shall document
my experience and the "easy" path I have chosen.
## Packaging
The websites I hosted were of two variety: those statically exported, and
those that cannot be statically exported.
### Statically Exported Webapps
Statically exported ones are easy to package, because it is a matter of
running `npm build` (or whatever your build script is) with the following
NextJS settings
```js
// next.config.js
module.exports = {
distDir: "dist", // an artitrary path for your export
output: "export",
};
```
This will export a static website with a bunch of html files that you can
then serve with nodePackages.serve or a webserver like nginx or apache.
And that is the end of your worries for a statically exported website! No
headache, just write a simple derivation, such as the one below
```nix
# default.nix
{
buildNpmPackage,
pkg-config,
python3,
...
}:
buildNpmPackage {
pname = "your-website";
version = "0.1";
src = ./.;
# needs to be updated everytime you update npm dependencies
npmDepsHash = "sha256-some-hash";
# some npm packages may need to be built from source, because nodejs is a *terrible* ecosystem
nativeBuildInputs = [pkg-config python3];
# move exported website to $out
postInstall = ''
cp -rf dist/* $out
'';
}
```
and serve its path with a simple tool after building the derivation, I find
nginx to be awfully convenient for doing so, but you may choose caddy if you
prefer.
### Webapps that cannot be statically exported
If your website depends on API routes for some reasons, then Next will not
allow you to do static export. Which means you need to run `next start` in
some shape or form. While a systemd service is certainly a way of doing it
(one that I do not recommend), a oci container works as well if not better.
You can write a "simple" docker image for your oci container to use, such as
the one below
```nix
# dockerImage.nix
{
pkgs,
inputs,
...
}: {
dockerImage = pkgs.dockerTools.buildImage {
config = {
WorkingDir = "/your-website";
Cmd = ["npm" "run" "serve"];
};
name = "your-website";
tag = "latest";
fromImage = pkgs.dockerTools.buildImage {
name = "node";
tag = "18-alpine";
};
copyToRoot = pkgs.buildEnv {
name = "image-root";
paths = with pkgs; [
# this package is called from a flake.nix alongside the derivation for the website
inputs.self.packages.${pkgs.system}.your-website
nodejs
bash
];
pathsToLink = [
"/bin"
"/your-website"
];
};
};
}
```
Then, configure oci-containers module option to pick up the Docker image that
you have built. This is a simplified version of my VPS' container setup.
An example can be found in my [server module](https://github.com/NotAShelf/nyx/blob/a9e129663ac91302f2fd935351a71cbbd2832f64/modules/core/roles/server/system/services/mkm.nix)
```nix
virtualisation.oci-containers = {
backend = "podman";
containers = {
"website-container" = {
autoStart = true;
ports = [
"3000:3000" # bind container's port 3000 to the outside port 3000 for NextJS
];
extraOptions = ["--network=host"];
image = "your-website";
imageFile = inputs.website-flake.packages.${pkgs.system}.dockerImage;
};
};
};
```
After a rebuild, your system will provision the container and start it on
port **3000**. You can access it with `your-server-ip:3000` in your
browser, and even configure nginx to set up a reverse proxy to assign
your domain.
```conf
"example.com" = {
locations."/".proxyPass = "http://127.0.0.1:3000";
};
```
This will assign your domain to your webserver, and allow outside
visitors to view your "awesome" NextJS webapp.

103
nyx/docs/notes/2023-06-07-extended-nixpkgs.md Normal file
View file

@ -0,0 +1,103 @@
# Notes for 7th of June, 2023
Those are my notes on extending nixpkgs with your own functions and
abstractions. There may be other ways of doing it, but this is the one I find
to be most ergonomic.
## What is `nixpkgs.lib`
In the context of the Nix package manager and NixOS, `nixpkgs.lib` refers to
a module within the Nixpkgs repository. The `nixpkgs.lib` module provides a
set of utility functions and definitions that are commonly used across the
Nixpkgs repository. It contains various helper functions and abstractions that
make it easier to write Nix expressions and define packages. We often use those
functions to simplify our configurations and the nix package build processes.
## Why would you need to extend `nixpkgs.lib`
While the library functions provided by nixpkgs is quite extensive and usually
suits my needs, I sometimes feel the need to define my own function or wrap an
existing function to complete a task. Normally we can handle the process of a
function inside a simple `let in` and be well off, but there may be times you
need to re-use the existing function across your configuration file.
In such times, you might want to either write your own lib and inherit it at
the source of your `flake.nix` to then inherit them across your configuration.
Today's notes document the process of doing exactly that.
## Extending `nixpkgs.lib`
I find the easiest way of extending nixpkgs.lib to be using an overlay.
```nix
# lib/default.nix
{
nixpkgs,
lib,
inputs,
...
}: nixpkgs.lib.extend (
final: prev: {
# your functions go here
}
)
```
The above structure takes the existing `lib` from `nixpkgs`, and appends your
own configurations to it. You may then import this library in your `flake.nix`
to pass it to other imports and definitions.
```nix
# flake.nix
flake = let
# extended nixpkgs lib, contains my custom functions
lib = import ./lib {inherit nixpkgs lib inputs;};
in {
# entry-point for nixos configurations
nixosConfigurations = import ./hosts {inherit nixpkgs self lib;};
};
```
In this example (see my `flake.nix` for the actual implementation) I import my
extended lib from `lib/default.nix`, where I defined the overlay. I then pass
the extended lib to my `nixosConfiguratiıns`, which is an entry-point for all
of my NixOS configurations. As such, I am able to re-use my own utility
functions across my system as I see fit.
The problem with this approach is that it may be confusing for other people
reviewing your configuration. With this approach, `lib.customFunction` looks
identical to any lib function, which may lead to people thinking the function
exists in nixpkgs itself while it is only provided by your configuration. The
solution for that is simple though, instead of extending `nixpkgs.lib`, you may
define your own lib that does not inherit from `nixpkgs.lib` and only contains
your functions. The process would be similar, and you would not need to define
an overlay.
```nix
# flake.nix
flake = let
# extended nixpkgs lib, contains my custom functions
lib' = import ./lib {inherit nixpkgs lib inputs;};
in {
# entry-point for nixos configurations
nixosConfigurations = import ./hosts {inherit nixpkgs self lib';};
};
```
where your `lib/default.nix` looks like
```nix
# lib/default.nix
{
nixpkgs,
lib,
inputs,
...
}: {
# your functions here
}
```
You can find a real life example of the alternative approach in
my [neovim-flake's lib](https://github.com/NotAShelf/neovim-flake/blob/main/lib/stdlib-extended.nix).

82
nyx/docs/notes/2023-07-14-openssh-custom-port.md Normal file
View file

@ -0,0 +1,82 @@
# Notes for 14th of July, 2023
My VPS, which hosts some of my infrastructure, has been running NixOS
for a while now. Although weak, I use it for distributed builds alongside the
rest of my NixOS machines on a Tailscale network.
This server, due to it hosting my infrastructure that communicates with the
rest of the internet (i.e my mailserver), is somewhat responsive to queries
from the public - which includes _very_ agressive portscans (thanks, skiddies!)
To mitigate that, I have decided to change the ssh port from the default **22**
to something different. While this is not exactly a pancea, it helps alleviate
the insane log spam I get from failed ssh requests.
## The OpenSSH Configuration
First thing we've done is to configure openssh to listen on the new port on
your server configuration
```nix
services.openssh = {
ports = [2222];
}
```
With this set, openssh on the server will now be listening on the port **2222**
instead of the default **22**. For the changes to take effect after a
rebuild, you might need to run `systemctl restart sshd.socket`.
Then we want to configure our client to use the correct port for our server
instead of the default **22**.
```nix
programs.ssh.extraConfig = ''
Host nix-builder
HostName nix-builder-hostname # if you are using Tailscale, this can just be the hostname of a device on your Tailscale network
Port 2222
'';
```
And done, that is all for the ssh side of things. Next up, we need to configure
out builder to use the correct host.
## Nix Builder Configuration
Assuming you already have a remote builder configured, you will only need to
patch the `hostName` with the one on your `openssh.extraConfig`.
```nix
nix.buildMachines = [{
hostName = "nix-builder-hostname";
sshUser = "nix-builder";
sshKey = "/path/to/key";
systems = ["x86_64-linux"];
maxJobs = 2;
speedFactor = 2;
supportedFeatures = ["kvm"];
}];
```
If you have added the correct `hostName` and `sshUser`, the builder will be
picked up automatically on the next rebuild.
### Home-Manager
If you are using Home-Manager, you might also want to configure your
declarative ~/.config/ssh/config to use the new port. That can be achieved
through `programs.ssh.matchBlocks` option under Home-Manager
```nix
programs.ssh.matchBlocks = {
"builder" = {
hostname = "nix-builder-hostname";
user = "nix-builder";
identityFile = "~/.ssh/builder-key";
port = 2222;
};
}
```
And that will be all. You are ready to use your new non-default port, mostly
safe from port scanners.

88
nyx/docs/notes/2023-11-11-using-headscale.md Normal file
View file

@ -0,0 +1,88 @@
# Notes for 11th of November, 2023
Today's main attraction is the Headscale setup on my VPS running NixOS, which
I've finally came around to self-host.
There has been much talk about this new product called Tailscale recently
around the web, especially in the last few years. Tailscale is a VPN
service that makes the devices and applications we own accessible anywhere
using the open source WireGuard protocol to establish encrypted point-to-point
connections. I have been using Tailscale for a while now, but in an effort
to move all of my services to self-owned hardware some of my services have
been moved over to my NixOS server over time.
Many of Tailscale’s components are open-source, especially its clients, but
the server remains closed-source. Tailscale is a SaaS product and monetization
naturally is a big concern, however, we care more about controlling our own data
than their attempts of monetization.
This is where the (very appropriately named) Headscale comes in; Headscale is
an open-source, self-hosted implementation of the Tailscale control server. The
configuration is extremely straightforward, as Headscale will handle everything
for us.
## Running Headscale
Below is a simple configuration for the Headscale module of NixOS.
```nix
services = let
domain = "example.com";
in {
headscale = {
enable = true;
address = "0.0.0.0";
port = 8085;
settings = {
server_url = "https://tailscale.${domain}";
dns_config = {
override_local_dns = true;
base_domain = "${domain}";
magic_dns = true;
domains = ["tailscale.${domain}"];
nameservers = [
"9.9.9.9" # no cloudflare, nice
];
};
ip_prefixes = [
"100.64.0.0/10"
"fd7a:115c:a1e0::/48"
];
};
};
};
```
## Using Headscale
We must first create a user, which we can do with
```console
headscale users create myUser
```
Then on the machine that will be our client, we need to login.
```console
tailscale up --login-server tailscale.example.com # replace this URL with your own as configured abovea
```
Followed by registering the machine.
```console
# machine key will be obtained visiting the URL that is returned from the above command
headscale --user myUser nodes register --key <MACHINE_KEY>
```
And finally logging into your Tailnet using the URL and your machine key.
```console
tailscale up --login-server https://tailscale.example.com --authkey <YOUR_AUTH_KEY>
```
And all done! Now try connecting to one of your machines using the hostname now
to test if the connection is actually working. If anything goes wrong, make
sure to check your DNS settings: remember, it's always the DNS.

29
nyx/docs/notes/README.md Normal file
View file

@ -0,0 +1,29 @@
# Notes
Howdy! Welcome to my collection of notes.
This is where I store my notes on topics and processes that I find particularly
difficult, obscure or otherwise interesting. Mostly on Linux and NixOS,
perhaps on programming in the future.
If those notes helped you in any way, that is great! That means my time writing
those notes were well spent. If you were already a Nix/NixOS expert who somehow
found their way in here, and got really bored reading my notes then I only ask
that you point out my mistakes where you spot them. Your time will be very much
appreciated.
If you are a reader looking for some pro tips, I would like to remind you that I
am not an expert in Nix or NixOS. My notes are limited by my own knowledge.
However, I would be happy to try and answer your questions nevertheless; and we
can try figuring out the answer together, should we both happen to be stuck.
If you spot a mistake, please let me know and I would be happy to learn from you.
Thanks!
| Date | Category | Description |
| ---------- | ---------- | -------------------------------------------------------------------------------------------------- |
| 22-01-2023 | Linux | My notes on a kernel parameter change affecting my backlight state |
| 14-03-2023 | Nix | Reproduction steps NixOS setup with ephemeral root using BTRFS subvolumes and full disk encryption |
| 07-06-2023 | Nix | Notes on extending or writing your own nixpkgs library to use in your configurations |
| 21-06-2023 | Nix/NextJS | A guide on serving statically exported and non-statically exported NextJS Webapps on NixOS |
| 14-07-2023 | Nix/NixOS | Notes on a potentially working distributed builds setup on NixOS with a non-default ssh port |

48
nyx/docs/notes/cheatsheet.md Normal file
View file

@ -0,0 +1,48 @@
# Cheat sheet
## Show GC roots
```sh
nix-store --gc --print-roots | grep -v "<hostName>" | column -t | sort -k3 -k1
```
## List all packages
```sh
nix-store -q --requisites /run/current-system | cut -d- -f2- | sort | uniq
```
You can add a `wc -l` at the end of the above command, but that will not be an accurate representation of
your package count, as the same package can be repeated with different versions.
## Find biggest packages
```sh
nix path-info -hsr /run/current-system/ | sort -hrk2 | head -n10
```
## Find biggest closures (packages including dependencies)
```sh
nix path-info -hSr /run/current-system/ | sort -hrk2 | head -n10
```
## Show package dependencies as tree
> Assuming `hello` is in PATH
```sh
nix-store -q --tree $(realpath $(which hello))
```
## Show package dependencies including size
```sh
nix path-info -hSr nixpkgs#hello
```
## Show the things that will change on reboot
```sh
diff <(nix-store -qR /run/current-system) <(nix-store -qR /run/booted-system)
```

8
nyx/docs/notes/yubikey-todo.md Normal file
View file

@ -0,0 +1,8 @@
# TODO
<!--- Yubikey gpg setup & disk encryption on Nixos -->
## Resources
- https://superuser.com/questions/1628782/gpg-signing-failed-no-pinentry
- https://superuser.com/questions/397149/can-you-gpg-sign-old-commits