brainsik

Notes from running NixOS in a local VM.

The attached configuration.nix sets users immutable to force managing them through the config. The primary user is added to the wheel group and the wheel group has passwordless sudo access. All passwords are set by hash (using mkpasswd). SSH keys can be added for the primary user and/or Tailscale SSH can be enabled.

Manual installation

Everything below is run as root.

Partition, format, mount, configure:

brainsik

[
    {
        "minStats": 360
    },
    {
        "minBlessingRarity": 3,
        "item": [
            "Staff"
        ]
    },

brainsik

# $URL - the url to mirror
# $PATH - where to put the httrack files

httrack $URL -O $PATH -v -x \
  --disable-security-limits \
  -F 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.6.1 Safari/605.1.15' \
  -c16 -%c32 -%k \
  -s0 -n -%u \
  '-*api.php*' '-*index.php*' '-*title=*' '-*Special:*' \
  '+*Special:SpecialPages' '+*Special:AllPages' '+*Special:Categories' \

brainsik

:root{
  /* editor mode */
  --text-editor: 'iA Writer Mono S';

  /* code */
  --font-monospace: 'FiraCode Nerd Font';
}

body {
  font-family: var(--default-font);

brainsik

Generate key

dd if=/dev/random of=keyfile count=1 bs=32

Upload file

Endpoint is found in the bucket details via console.

brainsik

#!/bin/sh
set -eu -o pipefail
set -x

version=$1

cd terraform-provider-aws
git fetch

git checkout .

brainsik

brew uninstall terraform
brew extract --version 0.11.14 terraform homebrew/cask
brew install terraform@0.11.14

brainsik

Minimalism

Minimalist infrastructure is the practice of building only what you need with the fewest number of resources. This is a philosophy, not a religion, you shouldn't build bad infrastructure to achieve a minimalist design. A minimalist design should lead to good infrastructure by reducing the amount of resources under management and the complexity of the design.

Avoid state

When designing your system, avoid storing additional state. Often the data you want to store is already available in the system. Using the system as the source of truth can avoid the difficult business of ensuring data consistency.

As an example, let's say you want to be able to rollback a Fargate deploy if the new task definition results in a service that won't become healthy. One option would be store the working task definition in something like DynamoDB (or git or any number of bad choices). However, your ECS service already has this information: the previous, healthy service is still running. Instead of managing a

brainsik

data "aws_vpc" "found" {
  count = "${length(var.vpc_names)}"

  filter {
    name = "tag:Name"
    values = ["${element(var.vpc_names, count.index)}"]
  }
}

output "vpc_id" {

brainsik

2018/07/24 15:01:38 [INFO] Terraform version: 0.11.7  
2018/07/24 15:01:38 [INFO] Go runtime version: go1.10.1
2018/07/24 15:01:38 [INFO] CLI args: []string{"/usr/local/Cellar/terraform/0.11.7/bin/terraform", "validate"}
2018/07/24 15:01:38 [DEBUG] Attempting to open CLI config file: /Users/jeremy.avnet/.terraformrc
2018/07/24 15:01:38 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2018/07/24 15:01:38 [INFO] CLI command args: []string{"validate"}
2018/07/24 15:01:38 [DEBUG] checking for provider in "."
2018/07/24 15:01:38 [DEBUG] checking for provider in "/usr/local/Cellar/terraform/0.11.7/bin"
2018/07/24 15:01:38 [DEBUG] checking for provider in ".terraform/plugins/darwin_amd64"
2018/07/24 15:01:38 [DEBUG] found provider "terraform-provider-aws_v1.28.0_x4"