UVOO Tech Wiki - User contributions [en]

Kube-virt - k8s in k8s

2026-08-02T15:11:02Z

Busk: Created page with "One of the most popular and powerful use cases for KubeVirt, often referred to as **Kubernetes-in-Kubernetes** or **Tenant Clusters**. In this architecture, your underlying b..."

One of the most popular and powerful use cases for KubeVirt, often referred to as **Kubernetes-in-Kubernetes** or **Tenant Clusters**.

In this architecture, your underlying bare-metal Kubernetes cluster acts as the **infrastructure management layer** (the control plane for hardware), and KubeVirt provisions VMs that join together to form separate, isolated **tenant Kubernetes clusters**.

---

## Why Do This? (Key Benefits)

* **Multi-Tenancy & Hard Isolation:** Containers share the host kernel. If you need strict security boundaries between teams or environments (e.g., Prod vs. Dev), VMs provide hardware-level virtualization isolation.
* **Infrastructure-as-Code (GitOps):** You can manage the lifecycle of entire target Kubernetes clusters declaratively using standard `kubectl` commands or GitOps pipelines (ArgoCD/Flux).
* **Cluster API (CAPI) Integration:** Using the **Cluster API Provider KubeVirt (CAPK)**, you can declare a target Kubernetes cluster in YAML, and CAPI + KubeVirt will automatically spin up the VMs, run `cloud-init` to install Kubernetes on them, and join them into a fully functional tenant cluster.
* **Testing & Sandbox Environments:** It allows developers to spin up ephemeral, full-featured Kubernetes clusters (with custom kernel modules or CNI configurations) without needing real physical hardware.

---

## How the Architecture Looks

```
┌────────────────────────────────────────────────────────────────────────┐
│ BARE-METAL KUBERNETES CLUSTER │
│ (Management Cluster: Physical Servers + Storage + KubeVirt Operator) │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ TENANT KUBERNETES CLUSTER │ │
│ │ │ │
│ │ ┌────────────────────┐ ┌────────────────────┐ │ │
│ │ │ KubeVirt VM 1 │ │ KubeVirt VM 2 │ │ │
│ │ │ (Tenant Control) │ │ (Tenant Worker) │ │ │
│ │ │ │ │ │ │ │
│ │ │ ┌────────────────┐ │ Network │ ┌────────────────┐ │ │ │
│ │ │ │ Tenant K8s API │ ◄────────────────►│ Tenant Pods │ │ │ │
│ │ │ └────────────────┘ │ (Overlay/VLAN) │ └────────────────┘ │ │ │
│ │ └────────────────────┘ └────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────────┘

```

---

## Typical Workflow

1. **Deploy Bare-Metal K8s:** You set up physical servers with a Kubernetes distribution (e.g., Talos, RKE2, OpenShift, or upstream K8s).
2. **Install KubeVirt:** Deploy the KubeVirt operator on the bare-metal cluster.
3. **Use Cluster API (CAPK):** Apply a manifest defining a tenant cluster (e.g., 1 Control Plane VM, 3 Worker VMs).
4. **Bootstrapping via cloud-init:** KubeVirt boots the VMs, and `cloud-init` runs scripts (like `kubeadm join` or `k3s`) to wire the nodes into the new nested cluster.

---

## Things to Consider

* **Nested Virtualization / Overhead:** Ensure hardware-assisted virtualization (`/dev/kvm`) is available on your bare-metal nodes so KubeVirt runs near native speed.
* **Networking:** You’ll need a CNI or plugin like **Multus** or **OVN-Kubernetes** on the bare-metal cluster to assign dedicated IPs or VLANs to the VM nodes so the tenant cluster can route traffic cleanly.

Openssl

2026-08-01T22:06:24Z

Busk:

openssl s_client -connect docker2:993 -servername docker2 </dev/null 2>/dev/null | openssl x509 -noout -subject

https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs

https://www.openssl.org/docs/manmaster/man5/x509v3_config.html

```
openssl s_client -connect ldaps.example.com:636 -showcerts </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName
```

```
echo -n | openssl s_client -connect google.com:443 2>/dev/null | openssl x509 -noout -text | grep -E 'Subject:|X509v3 Subject Alternative Name:'
openssl s_client -connect www.uvoo.me:443
echo | openssl s_client -showcerts -servername www.uvoo.me -connect www.uvoo.me:443 2>/dev/null | openssl x509 -inform pem -noout -text
```

Quicks like get subject alt names
```
openssl x509 -text -in my.crt.pem
openssl x509 -noout -ext subjectAltName
openssl x509 -noout -dates
```

# self signed cert pem
```
fqdn=${FQDN:-autogenerated-selfsigned-cert}; openssl req -x509 -nodes -days 3650 -newkey rsa:4096 -keyout selfsigned.key -out selfsigned.crt -subj "/CN=$fqdn" -addext "subjectAltName = DNS:$fqdn"

cat selfsigned.crt selfsigned.key >> aaa.pem
```

# Extract Certs from .pfx PKCS#12
```
openssl pkcs12 -passin env:PASSIN -in ${cn}.pfx -nocerts -nodes > ${cn}.key.pem
openssl pkcs12 -passin env:PASSIN -in ${cn}.pfx -clcerts -nokeys > ${cn}.crt.pem
openssl pkcs12 -passin env:PASSIN -in ${cn}.pfx -cacerts -nokeys -chain > ${cn}.ca.crt.pem
```

# validate
https://link.medium.com/9Cif8SlO9ub

# Pem
```
Donwload pem
openssl rsa -in ~/myhost.example.com.pem -out ~/myhost.example.com.pem.key
and replace encrypted private key at bottom in ~/myhost.example.com.pem with ~/myhost.example.com.pem.key
```

# pkcs12
```
echo -n | openssl s_client -showcerts -connect $HOST:$PORTNUMBER -servername $SERVERNAME \
| openssl x509 > /tmp/$SERVERNAME.cert

openssl pkcs12 -in <filename.pfx> -nocerts -nodes | sed -ne '/-BEGIN PRIVATE KEY-/,/-END PRIVATE KEY-/p' > <clientcert.key>
openssl pkcs12 -in <filename.pfx> -clcerts -nokeys | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <clientcert.cer>
openssl pkcs12 -in <filename.pfx> -cacerts -nokeys -chain | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <cacerts.cer>
```

Expiration dates
```
host=example.com; port=443; echo "Q" | openssl s_client -servername $host -connect $host:$port | openssl x509 -noout -dates
```

Show Certs
```
host=example.com; port=443; echo "Q" | openssl s_client -showcerts -connect $host:$port
```

Get CA cert PEM from URL and use with curl
```
host=example.com; port=443; echo quit | openssl s_client -showcerts -servername server -connect $host:$port > cacert.pem
host=example.com; port=443; curl -vv --cacert cacert.pem https://$host:$port/notifications/health
```
```
openssl pkcs12 -in example.io.pfx -out example.io.pem -nodes
```

# PKS
```
# kb.dev.example.com.pks
host=kb.dev.example.com; openssl pkcs12 -in $host.pfx -out $host.key -nocerts -nodes
host=kb.dev.example.com; openssl pkcs12 -in $host.pfx -out $host.crt -clcerts -nokeys
```

```
openssl pkcs12 -in <filename.pfx> -nocerts -nodes | sed -ne '/-BEGIN PRIVATE KEY-/,/-END PRIVATE KEY-/p' > <clientcert.key>
openssl pkcs12 -in <filename.pfx> -clcerts -nokeys | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <clientcert.cer>
openssl pkcs12 -in <filename.pfx> -cacerts -nokeys -chain | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <cacerts.cer>
```

cipher scans
```
echo quit | openssl s_client -connect www.uvoo.io:443 -msg -debug 2>/dev/null | grep "Cipher :"
```

Self signed https certs
```
View & Download in Firefox
PEM (cert)PEM (chain)
export API_HOST=example.com
echo quit | openssl s_client -showcerts -servername "${API_HOST}" -connect "${API_HOST}":443 > cacert.pem
curl --cacert cacert.pem --location --silent https://${API_HOST}
```

https://www.redhat.com/sysadmin/6-openssl-commands

# Extract cert and key
```
openssl pkcs12 -in domain.pfx -clcerts -nokeys -out domain.crt
openssl pkcs12 -in domain.pfx -nocerts -nodes -out domain.key
```

# Update your Apache configuration file with:

```
<VirtualHost 192.168.0.1:443>
...
SSLEngine on
SSLCertificateFile /path/to/domain.crt
SSLCertificateKeyFile /path/to/domain.key
...
</VirtualHost>
```

```
echo quit | openssl s_client -connect log.example.com:6514
echo "Q" | openssl s_client -servername google.com -connect google.com:443 | openssl x509 -noout -dates
host=example.com; port=443; echo "Q" | openssl s_client -servername $host -connect $host:$port | openssl x509 -noout -dates
```

```
echo quit | openssl s_client -showcerts -servername server -connect google.com:443 > cacert.pem
true | openssl s_client -connect google.com:443 2>/dev/null | openssl x509
rm -f cert.pem && echo -n | openssl s_client -connect google.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ./cert.pem
```
curl --cacert google.pem https://google.com

Get cipher
```
echo quit | openssl s_client -connect lb.examle.com:443 2>/dev/null | grep -i cipher
```

```
openssl s_client -connect 10.x.x.x:6514
```

PKI
```
#!/usr/bin/env bash
set -eu
# ref: https://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/

bits=4096
# cert_cn=insights.example.com
ca_dir=ca
keys_dir=ca/keys
mkdir -p $ca_dir
mkdir -p $keys_dir
# cd $ca_dir
ca_subject="-subj \"/C=US/ST=Utah/L=Lehi/O=Example/OU=IT/CN=ca.example.com\""

create_CA(){
echo "Configuring rootca certs for issueing certs to nodes via CN/fqdn."
openssl genrsa -out $ca_dir/ca.key $bits
openssl genrsa -des3 -out $ca_dir/ca.key $bits
# openssl genrsa -nodes -out $ca_dir/ca.key $bits
# openssl req -x509 -new -nodes -key $ca_dir/ca.key -sha256 -days 10240 -out $ca_dir/ca.pem $ca_subject
openssl req -x509 -new -nodes -key $ca_dir/ca.key -sha256 -days 10240 -out $ca_dir/ca.crt -subj "/C=US/ST=Utah/L=Lehi/O=Example/OU=IT/CN=ca.example.com"
}

create_client(){
cert_cn=$1
echo "Configuring certs for nodes with CN/fqdn."
openssl genrsa -out $keys_dir/${cert_cn}.key $bits
openssl req -new -key $keys_dir/${cert_cn}.key -out $keys_dir/${cert_cn}.csr -subj "/C=US/ST=Utah/L=Lehi/O=Example/OU=IT/CN=$cert_cn"
openssl x509 -req -in $keys_dir/${cert_cn}.csr -CA $ca_dir/ca.crt -CAkey $ca_dir/ca.key -CAcreateserial -out $keys_dir/${cert_cn}.crt -days 730 -sha256
}

copy_keys_to_rsyslog(){
cert_cn=$1
cp $keys_dir/${cert_cn}.key ../files/etc/rsyslog.d/keys/
cp $keys_dir/${cert_cn}.crt ../files/etc/rsyslog.d/keys/
cp $ca_dir/ca.crt ../files/etc/rsyslog.d/keys/
}

create_CA
create_client insights.example.com
copy_keys_to_rsyslog insights.example.com

# Notes

# sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt
```

# Shadow
```
openssl passwd -6 -salt ly7/kMnF yourpass
```

LDAP
```
openssl s_client -showcerts -connect ldap.yourdomain.com:636
```
# Refs
- https://deliciousbrains.com/ssl-certificate-authority-for-local-https-development/#becoming-certificate-authority
- https://github.com/OpenVPN/easy-rsa/blob/master/README.quickstart.md
- https://www.feistyduck.com/library/openssl-cookbook/online/ch-testing-with-openssl.html

# More

```
openssl s_client -connect 127.0.0.1:8443 -tls1_3

openssl s_client -showcerts -servername www.example.com -connect www.example.com:443 </dev/null

openssl s_client -showcerts -connect www.example.com:443 </dev/nul

$ echo | \
openssl s_client -servername www.example.com -connect www.example.com:443 2>/dev/null | \
openssl x509 -text
```

```
openssl verify -verbose -CAfile _.example.com.crt _.example.com.crt
```

get cert
```
openssl x509 -in a.crt -text -certopt no_header,no_pubkey,no_subject,no_issuer,no_signame,no_version,no_serial,no_validity,no
_extensions,no_sigdump,no_aux,no_extensions
```

pkcs12 from key and crt
```
openssl pkcs12 -export -out keyStore.p12 -inkey my.key -in my.crt
```

Swap space

2026-08-01T21:03:21Z

Busk:

# Linux

## Disable swap

# Disable swap immediately
sudo swapoff -a

# Comment out or remove any swap entries from /etc/fstab to persist on reboot
sudo sed -i.bak '/\bswap\b/s/^/#/' /etc/fstab

## Clear swap
```
free -m
swapoff -a
# wait about 30 seconds
swapon -a
```

## Check swappiness
```
sysctl -a | grep swap
vm.swappiness = 10
```

Gitlab runner LXD

2026-08-01T20:10:13Z

Busk: Created page with "https://docs.gitlab.com/runner/executors/custom_examples/lxd/ You need to **install the `gitlab-runner` apt package first**. Installing the package creates the `gitlab-runne..."

https://docs.gitlab.com/runner/executors/custom_examples/lxd/

You need to **install the `gitlab-runner` apt package first**.

Installing the package creates the `gitlab-runner` system user and the `/etc/gitlab-runner/` directory structure where `config.toml` lives.

Here is the step-by-step order of operations to get everything set up correctly:

---

## Step 1: Install the GitLab Runner Package

Run these commands on your host machine to add GitLab's official repository and install the runner:

```bash
# 1. Download and run the official GitLab repository setup script
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

# 2. Install the gitlab-runner package
sudo apt-get install gitlab-runner

```

---

## Step 2: Create the LXD Executor Scripts

Next, create your wrapper scripts for the custom executor (e.g., in `/opt/gitlab-runner/`).

```bash
# Create directory for custom executor scripts
sudo mkdir -p /opt/gitlab-runner

# Create the prepare, run, and cleanup scripts
sudo touch /opt/gitlab-runner/lxd-prepare.sh
sudo touch /opt/gitlab-runner/lxd-run.sh
sudo touch /opt/gitlab-runner/lxd-cleanup.sh

# Make them executable
sudo chmod +x /opt/gitlab-runner/lxd-*.sh

```

*(Paste the script contents into these files and ensure the LXD TLS certificate generation step you performed earlier is configured under the `gitlab-runner` system user's home directory so it can authenticate against LXD).*

---

## Step 3: Register and Configure `config.toml`

Finally, register the runner with your GitLab instance, which will automatically generate or update `/etc/gitlab-runner/config.toml`.

```bash
# Register the runner (you'll need a registration token from GitLab UI)
sudo gitlab-runner register \
--non-interactive \
--url "https://gitlab.com/" \
--token "YOUR_RUNNER_AUTHENTICATION_TOKEN" \
--executor "custom" \
--description "lxd-restricted-runner" \
--custom-prepare-exec "/opt/gitlab-runner/lxd-prepare.sh" \
--custom-run-exec "/opt/gitlab-runner/lxd-run.sh" \
--custom-cleanup-exec "/opt/gitlab-runner/lxd-cleanup.sh"

```

Once registered, you can edit `/etc/gitlab-runner/config.toml` directly if you need to fine-tune concurrency limits or execution parameters.

Kubernetes Bare Metal

2026-08-01T19:26:06Z

Busk: Created page with "https://www.digitalocean.com/community/tutorials/bare-metal-kubernetes You probably want to use cloud-init like this Ubuntu 24.04 `cloud-init` configuration for provisioning..."

https://www.digitalocean.com/community/tutorials/bare-metal-kubernetes

You probably want to use cloud-init like this Ubuntu 24.04

`cloud-init` configuration for provisioning Kubernetes nodes on **Ubuntu 24.04 LTS**.

This script handles:

* Disabling swap (required by `kubelet`)
* Enabling necessary kernel modules (`overlay`, `br_netfilter`)
* Setting required `sysctl` networking parameters
* Installing and configuring `containerd` with the `SystemdCgroup` driver enabled
* Adding the official `pkgs.k8s.io` repository (configured for Kubernetes **v1.30**)
* Installing and locking (`apt-mark hold`) `kubelet`, `kubeadm`, and `kubectl`

---

## Cloud-Init YAML (`user-data`)

```yaml
#cloud-config
package_update: true
package_upgrade: false

packages:
- apt-transport-https
- ca-certificates
- curl
- gpg
- containerd

write_files:
# Enable required kernel modules for container networking
- path: /etc/modules-load.d/k8s.conf
permissions: '0644'
content: |
overlay
br_netfilter

# Set sysctl rules for iptables bridge & IP forwarding
- path: /etc/sysctl.d/k8s.conf
permissions: '0644'
content: |
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1

runcmd:
# 1. Disable swap immediately and persistently across reboots
- swapoff -a
- sed -i '/ swap / s/^$.*$$/#\1/g' /etc/fstab

# 2. Load kernel modules and apply sysctl settings
- modprobe overlay
- modprobe br_netfilter
- sysctl --system

# 3. Configure containerd with SystemdCgroup enabled
- mkdir -p /etc/containerd
- containerd config default | tee /etc/containerd/config.toml > /dev/null
- sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml
- systemctl restart containerd
- systemctl enable containerd

# 4. Add official Kubernetes v1.30 apt repository
- mkdir -p -m 755 /etc/apt/keyrings
- curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
- chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg
- echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | tee /etc/apt/sources.list.d/kubernetes.list

# 5. Install Kubernetes binaries and prevent auto-upgrades
- apt-get update
- apt-get install -y kubelet kubeadm kubectl
- apt-mark hold kubelet kubeadm kubectl
- systemctl enable --now kubelet

```

---

## Next Steps After Boot

Once your machine finishes running `cloud-init`, choose your role:

### For the Control Plane (Master Node)

Initialize the cluster with your control plane IP and preferred pod CIDR (e.g., Flannel/Calico):

```bash
sudo kubeadm init --pod-network-cidr=10.244.0.0/16

```

### For Worker Nodes

Run the `kubeadm join` command provided at the end of your control plane's `kubeadm init` output.

AWS vs Azure

2026-08-01T15:46:53Z

Busk:

Here is how the core AWS services map directly to their Azure counterparts across key infrastructure categories:

### Core Service Mapping

| Category | AWS Service | Azure Equivalent | Description |
| --- | --- | --- | --- |
| **Compute** | **EC2** | Virtual Machines (VMs) | On-demand virtual instances/servers. |
| | **AWS Lambda** | Azure Functions | Event-driven serverless compute. |
| | **Elastic Beanstalk** | Azure App Service | Managed PaaS for web app deployment. |
| **Containers** | **EKS** | Azure Kubernetes Service (AKS) | Managed Kubernetes engine. |
| | **ECS / Fargate** | Azure Container Apps / ACI | Serverless container execution. |
| | **ECR** | Azure Container Registry (ACR) | Docker/OCI image repository. |
| **Storage** | **S3** | Azure Blob Storage | Scalable object storage. |
| | **EBS** | Azure Managed Disks | Block storage attached to compute instances. |
| | **EFS / FSx** | Azure Files | Fully managed network file shares (NFS/SMB). |
| | **S3 Glacier** | Azure Archive Storage | Cold/archival storage for backups. |
| **Databases** | **RDS** | Azure SQL Database / Flexible Server | Managed relational databases (PostgreSQL, MySQL, SQL Server). |
| | **DynamoDB** | Azure Cosmos DB | Fully managed NoSQL key-value/document database. |
| | **ElastiCache** | Azure Cache for Redis | In-memory caching. |
| **Networking** | **VPC** | Virtual Network (VNet) | Isolated private cloud networking. |
| | **Route 53** | Azure DNS | Managed DNS routing service. |
| | **Direct Connect** | Azure ExpressRoute | Dedicated private link to on-premise hardware. |
| | **ALB / NLB** | Application Gateway / Load Balancer | Layer 7 (HTTP/HTTPS) and Layer 4 load balancing. |
| **Identity & Security** | **AWS IAM** | Microsoft Entra ID (Azure AD) + RBAC | Identity management, auth, and role definitions. |
| | **AWS KMS** | Azure Key Vault | Key, secret, and certificate management. |
| | **AWS Shield / WAF** | Azure DDoS Protection / Web Application Firewall | DDoS defense and application security. |
| **Analytics & AI** | **Redshift** | Azure Synapse Analytics | Cloud data warehousing. |
| | **Amazon SageMaker** | Azure Machine Learning | Platform for building, training, and deploying ML models. |
| | **AWS Glue** | Azure Data Factory | Managed ETL and data integration pipelines. |

---

### Key Structural Differences

* **Identity Model:** AWS centers permissions around IAM policies attached to users/roles via JSON documents. Azure heavily relies on Microsoft Entra ID with Role-Based Access Control (RBAC) applied across standard scope hierarchies (Management Groups → Subscriptions → Resource Groups → Resources).
* **Resource Management:** Azure mandates that every resource resides within a **Resource Group** for unified lifecycle management. AWS tags resources globally or groups them logically, but lacks the strict single-container grouping model native to Azure.

**for most greenfield projects, standard microservices, and general container workloads, Fargate is the default best choice.**

The reduced configuration, lack of node management (no OS patching, no AMI rotations, no cluster autoscaling setup), and per-task scaling make it the lower-overhead option for developer velocity.

However, saying it’s *only* when resources are "mostly pegged" misses a few critical non-cost boundaries where Fargate simply cannot be used or becomes significantly more expensive.

---

### Non-Cost Constraints (When Fargate Is Not an Option)

Sometimes you **must** use EC2 regardless of price or utilization:

1. **GPU / Specialized Hardware Workloads:** Machine learning inference/training (NVIDIA GPUs), high-performance media encoding, or AWS Inferentia/Trainium hardware require EC2 instance types. Fargate doesn't support GPU pass-through.
2. **Custom Daemon / Host-Level Monitoring:** If you rely on daemonsets/agents that must run at the host OS level (e.g., specific kernel-level eBPF tracing, custom security agents, or system-wide log forwarders), Fargate’s serverless boundary prevents host access. Sidecar containers are required on Fargate instead.
3. **Privileged Mode & Kernel Tweaks:** Tasks requiring Linux `--privileged` access, custom kernel module loading, raw network sockets, or `sysctl` modifications are blocked by Fargate’s isolation boundary.
4. **Extreme Local Disk I/O:** Fargate task storage tops out at 200 GB of ephemeral storage. If your app requires terabytes of high-speed local NVMe scratch disk (like `i3en` or `z1d` instances), you need EC2.

---

### Cost Decision Matrix

```
Is the workload continuous & predictable?
/ \
/ \
YES NO (Bursty / Batch / Variable)
/ \
Are you running high-volume baseline? --> Use FARGATE
/ \ (Zero idle capacity waste)
/ \
YES NO
/ \
Are you using 3-yr Savings --> Use FARGATE
Plans + tight bin-packing? (Engineering time > ~20% savings)
/
YES
/
Use EC2
(Save up to 50%+)

```

---

### Summary Checklist

| Dimension | Default Choice | Shift to EC2 when... |
| --- | --- | --- |
| **Operational Effort** | **Fargate** (Zero node maintenance) | You already have robust node automation (e.g., Karpenter/Cluster Autoscaler) and dedicated DevOps resource. |
| **Scale Mechanism** | **Fargate** (Fast task provisioning) | Scaling is predictable and you can handle warm node pools. |
| **Hardware** | **Fargate** (Standard CPU/ARM + RAM) | You require GPUs, host storage, or kernel/privileged access. |
| **Cost at Scale** | **Fargate** (No waste from idle nodes) | Your monthly compute bill is large enough ($5k–$10k+/mo) that saving 30–50% pays for the engineering time to manage nodes. |

AWS vs Azure

2026-08-01T15:46:15Z

Busk: Created page with "**for most greenfield projects, standard microservices, and general container workloads, Fargate is the default best choice.** The reduced configuration, lack of node managem..."

**for most greenfield projects, standard microservices, and general container workloads, Fargate is the default best choice.**

The reduced configuration, lack of node management (no OS patching, no AMI rotations, no cluster autoscaling setup), and per-task scaling make it the lower-overhead option for developer velocity.

However, saying it’s *only* when resources are "mostly pegged" misses a few critical non-cost boundaries where Fargate simply cannot be used or becomes significantly more expensive.

---

### Non-Cost Constraints (When Fargate Is Not an Option)

Sometimes you **must** use EC2 regardless of price or utilization:

1. **GPU / Specialized Hardware Workloads:** Machine learning inference/training (NVIDIA GPUs), high-performance media encoding, or AWS Inferentia/Trainium hardware require EC2 instance types. Fargate doesn't support GPU pass-through.
2. **Custom Daemon / Host-Level Monitoring:** If you rely on daemonsets/agents that must run at the host OS level (e.g., specific kernel-level eBPF tracing, custom security agents, or system-wide log forwarders), Fargate’s serverless boundary prevents host access. Sidecar containers are required on Fargate instead.
3. **Privileged Mode & Kernel Tweaks:** Tasks requiring Linux `--privileged` access, custom kernel module loading, raw network sockets, or `sysctl` modifications are blocked by Fargate’s isolation boundary.
4. **Extreme Local Disk I/O:** Fargate task storage tops out at 200 GB of ephemeral storage. If your app requires terabytes of high-speed local NVMe scratch disk (like `i3en` or `z1d` instances), you need EC2.

---

### Cost Decision Matrix

```
Is the workload continuous & predictable?
/ \
/ \
YES NO (Bursty / Batch / Variable)
/ \
Are you running high-volume baseline? --> Use FARGATE
/ \ (Zero idle capacity waste)
/ \
YES NO
/ \
Are you using 3-yr Savings --> Use FARGATE
Plans + tight bin-packing? (Engineering time > ~20% savings)
/
YES
/
Use EC2
(Save up to 50%+)

```

---

### Summary Checklist

| Dimension | Default Choice | Shift to EC2 when... |
| --- | --- | --- |
| **Operational Effort** | **Fargate** (Zero node maintenance) | You already have robust node automation (e.g., Karpenter/Cluster Autoscaler) and dedicated DevOps resource. |
| **Scale Mechanism** | **Fargate** (Fast task provisioning) | Scaling is predictable and you can handle warm node pools. |
| **Hardware** | **Fargate** (Standard CPU/ARM + RAM) | You require GPUs, host storage, or kernel/privileged access. |
| **Cost at Scale** | **Fargate** (No waste from idle nodes) | Your monthly compute bill is large enough ($5k–$10k+/mo) that saving 30–50% pays for the engineering time to manage nodes. |

Saltstack docker

2026-07-31T07:15:26Z

Busk:

```
services:
salt-master:
image: saltstack/salt:latest
container_name: salt-master
restart: unless-stopped
ports:
- "4505:4505"
- "4506:4506"
volumes:
- ./config/master:/etc/salt/master:ro
- salt-pki:/etc/salt/pki
- ./srv/salt:/srv/salt
- ./srv/pillar:/srv/pillar
- salt-cache:/var/cache/salt
- salt-run:/var/run/salt

watchtower:
image: containrrr/watchtower
container_name: watchtower
restart: unless-stopped
environment:
# Run at 2:00 AM every night
# Format: Seconds Minutes Hours DayOfMonth Month DayOfWeek
- WATCHTOWER_SCHEDULE=0 0 2 * * *
# Remove old unpatched image layers from disk after updating
- WATCHTOWER_CLEANUP=true
# Check for base image updates regardless of local tag
- WATCHTOWER_INCLUDE_RESTARTING=true
volumes:
# CRITICAL: This must point to the rootless user's socket, not /var/run!
# Replace '1001' with the output of `id -u`
- /run/user/1001/docker.sock:/var/run/docker.sock
# Restrict Watchtower to ONLY update the salt-master container
command: salt-master

volumes:
salt-pki:
salt-cache:
salt-run:
```

```
#!/bin/bash
set -e

# ==========================================
# CONFIGURATION
# ==========================================
# Replace with your Dockerized Salt Master's IP or DNS name
SALT_MASTER="mysalt.example.com"

# Uses the machine's hostname by default, or you can hardcode a name (e.g., "web-server-01")
MINION_ID=$(hostname)
# ==========================================

if [[ $EUID -ne 0 ]]; then
echo "Error: This script must be run as root. Try using: sudo $0"
exit 1
fi

echo "==> Installing prerequisites..."
apt-get update
apt-get install -y curl gnupg

echo "==> Adding Salt Project repository for Ubuntu 24.04 LTS (Noble)..."
mkdir -p /etc/apt/keyrings
curl -fsSL -o /etc/apt/keyrings/salt-archive-keyring-2023.gpg \
https://repo.saltproject.io/salt/py3/ubuntu/24.04/amd64/SALT-PROJECT-GPG-PUBKEY-2023.gpg

echo "deb [signed-by=/etc/apt/keyrings/salt-archive-keyring-2023.gpg arch=amd64] https://repo.saltproject.io/salt/py3/ubuntu/24.04/amd64/3006 noble main" \
| tee /etc/apt/sources.list.d/salt.list > /dev/null

echo "==> Installing Salt Minion..."
apt-get update
apt-get install -y salt-minion

echo "==> Configuring Minion to connect to $SALT_MASTER..."
mkdir -p /etc/salt/minion.d
echo "master: $SALT_MASTER" > /etc/salt/minion.d/master.conf
echo "$MINION_ID" > /etc/salt/minion_id

echo "==> Enabling and starting Salt Minion service..."
systemctl enable --now salt-minion
systemctl restart salt-minion

echo "=================================================="
echo "Success! The Salt Minion ($MINION_ID) is running."
echo "It has sent its public key to $SALT_MASTER."
echo "You must now log into the Master server and accept this key."
echo "=================================================="
```

```
# List pending keys to verify the minion showed up
docker compose exec salt-master salt-key -L

# Accept the specific minion key
docker compose exec salt-master salt-key -a
```

Saltstack docker

2026-07-31T07:14:03Z

Busk: Created page with "``` #!/bin/bash set -e # ========================================== # CONFIGURATION # ========================================== # Replace with your Dockerized Salt Master's..."

```
#!/bin/bash
set -e

# ==========================================
# CONFIGURATION
# ==========================================
# Replace with your Dockerized Salt Master's IP or DNS name
SALT_MASTER="mysalt.example.com"

# Uses the machine's hostname by default, or you can hardcode a name (e.g., "web-server-01")
MINION_ID=$(hostname)
# ==========================================

if [[ $EUID -ne 0 ]]; then
echo "Error: This script must be run as root. Try using: sudo $0"
exit 1
fi

echo "==> Installing prerequisites..."
apt-get update
apt-get install -y curl gnupg

echo "==> Adding Salt Project repository for Ubuntu 24.04 LTS (Noble)..."
mkdir -p /etc/apt/keyrings
curl -fsSL -o /etc/apt/keyrings/salt-archive-keyring-2023.gpg \
https://repo.saltproject.io/salt/py3/ubuntu/24.04/amd64/SALT-PROJECT-GPG-PUBKEY-2023.gpg

echo "deb [signed-by=/etc/apt/keyrings/salt-archive-keyring-2023.gpg arch=amd64] https://repo.saltproject.io/salt/py3/ubuntu/24.04/amd64/3006 noble main" \
| tee /etc/apt/sources.list.d/salt.list > /dev/null

echo "==> Installing Salt Minion..."
apt-get update
apt-get install -y salt-minion

echo "==> Configuring Minion to connect to $SALT_MASTER..."
mkdir -p /etc/salt/minion.d
echo "master: $SALT_MASTER" > /etc/salt/minion.d/master.conf
echo "$MINION_ID" > /etc/salt/minion_id

echo "==> Enabling and starting Salt Minion service..."
systemctl enable --now salt-minion
systemctl restart salt-minion

echo "=================================================="
echo "Success! The Salt Minion ($MINION_ID) is running."
echo "It has sent its public key to $SALT_MASTER."
echo "You must now log into the Master server and accept this key."
echo "=================================================="
```

```
# List pending keys to verify the minion showed up
docker compose exec salt-master salt-key -L

# Accept the specific minion key
docker compose exec salt-master salt-key -a
```

Rootless docker

2026-07-31T02:30:32Z

Busk:

Works on Ubuntu 24.04

https://docs.docker.com/engine/security/rootless/

install-rootless-docker-on-ubuntu.sh
```
#!/bin/bash
set -e

SERVICE_USER="dockeruser"

# 1. Ensure script is run with sudo/root privileges
if [[ $EUID -ne 0 ]]; then
echo "Error: This script must be run as root. Try using: sudo $0"
exit 1
fi

# ==========================================
# 2. PRE-SCRIPT SECTION
# ==========================================
echo "==> Running pre-installation tasks..."
# Add any commands you want to run before the setup begins right here.
# For example, you could source an external script if it exists:
# if [ -f "./pre-install.sh" ]; then
# source ./pre-install.sh
# fi
#
# apt-get remove -y docker.io || true # Example: remove old conflicting packages

# ==========================================
# 3. DOCKER-CE & DEPENDENCY INSTALLATION
# ==========================================
echo "==> Setting up Docker's official apt repository..."
apt-get update
apt-get install -y ca-certificates curl
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
tee /etc/apt/sources.list.d/docker.list > /dev/null

echo "==> Installing docker-ce and rootless dependencies..."
apt-get update
apt-get install -y \
docker-ce docker-ce-cli containerd.io \
docker-buildx-plugin docker-compose-plugin \
docker-ce-rootless-extras uidmap dbus-user-session slirp4netns

# ==========================================
# 4. SYSTEM CONFIGURATION & ROOTLESS SETUP
# ==========================================
echo "==> Configuring Ubuntu 24.04 unprivileged user namespaces..."
sysctl -w kernel.unprivileged_userns_clone=1
echo "kernel.unprivileged_userns_clone=1" > /etc/sysctl.d/50-rootless-docker.conf

echo "==> Stopping and disabling rootful Docker to prevent socket conflicts..."
systemctl stop docker.service docker.socket || true
systemctl disable docker.service docker.socket || true
rm -f /var/run/docker.sock

echo "==> Creating dedicated user: $SERVICE_USER..."
if id "$SERVICE_USER" &>/dev/null; then
echo "User $SERVICE_USER already exists, skipping creation."
else
useradd -m -s /bin/bash "$SERVICE_USER"
echo "User $SERVICE_USER created successfully."
fi

echo "==> Enabling user lingering (ensures containers run without active SSH session)..."
loginctl enable-linger "$SERVICE_USER"

# Wait a moment for systemd to initialize the new user's DBUS environment
sleep 2

echo "==> Installing Rootless Docker as $SERVICE_USER..."
sudo -i -u "$SERVICE_USER" bash << 'EOF'
# Define systemd runtime variables for the user session
export XDG_RUNTIME_DIR="/run/user/$(id -u)"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"

# Run the rootless installer
dockerd-rootless-setuptool.sh install

# Configure .bashrc for future logins
if ! grep -q "DOCKER_HOST" ~/.bashrc; then
echo 'export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock' >> ~/.bashrc
echo 'export PATH=/usr/bin:$PATH' >> ~/.bashrc
fi

# Start and enable the systemd service for Docker
systemctl --user enable --now docker

echo "==> Rootless Docker installed successfully for $(whoami)!"
docker info | grep -i rootless
EOF

echo "==> Script complete!"
echo "To manage your containers, switch to the new user by running:"
echo "sudo su - $SERVICE_USER"
```

Rootless docker

2026-07-31T02:01:46Z

Busk:

Rootless docker

2026-07-31T02:00:06Z

Busk: Created page with "Works on Ubuntu 24.04 install-rootless-docker-on-ubuntu.sh ``` #!/bin/bash set -e SERVICE_USER="dockeruser" # 1. Ensure script is run with sudo/root privileges if $EUID..."

Works on Ubuntu 24.04

install-rootless-docker-on-ubuntu.sh
```
#!/bin/bash
set -e

SERVICE_USER="dockeruser"

# 1. Ensure script is run with sudo/root privileges
if [[ $EUID -ne 0 ]]; then
echo "Error: This script must be run as root. Try using: sudo $0"
exit 1
fi

echo "==> Installing dependencies..."
apt-get update
apt-get install -y uidmap dbus-user-session slirp4netns docker-ce-rootless-extras

echo "==> Configuring Ubuntu 24.04 unprivileged user namespaces..."
sysctl -w kernel.unprivileged_userns_clone=1
echo "kernel.unprivileged_userns_clone=1" > /etc/sysctl.d/50-rootless-docker.conf

echo "==> Stopping and disabling rootful Docker to prevent socket conflicts..."
systemctl stop docker.service docker.socket || true
systemctl disable docker.service docker.socket || true
rm -f /var/run/docker.sock

echo "==> Creating dedicated user: $SERVICE_USER..."
if id "$SERVICE_USER" &>/dev/null; then
echo "User $SERVICE_USER already exists, skipping creation."
else
useradd -m -s /bin/bash "$SERVICE_USER"
echo "User $SERVICE_USER created successfully."
fi

echo "==> Enabling user lingering (ensures containers run without active SSH session)..."
loginctl enable-linger "$SERVICE_USER"

# Wait a moment for systemd to initialize the new user's DBUS environment
sleep 2

echo "==> Installing Rootless Docker as $SERVICE_USER..."
# We use sudo to switch users and explicitly set XDG_RUNTIME_DIR so systemctl --user works
sudo -i -u "$SERVICE_USER" bash << 'EOF'
# Define systemd runtime variables for the user session
export XDG_RUNTIME_DIR="/run/user/$(id -u)"
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"

# Run the rootless installer
dockerd-rootless-setuptool.sh install

# Configure .bashrc for future logins
if ! grep -q "DOCKER_HOST" ~/.bashrc; then
echo 'export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock' >> ~/.bashrc
echo 'export PATH=/usr/bin:$PATH' >> ~/.bashrc
fi

# Start and enable the systemd service for Docker
systemctl --user enable --now docker

echo "==> Rootless Docker installed successfully for $(whoami)!"
docker info | grep -i rootless
EOF

echo "==> Script complete!"
echo "To manage your containers, switch to the new user by running:"
echo "sudo su - $SERVICE_USER"
```

Tpm2

2026-07-31T01:03:51Z

Busk:

Ubuntu 24.04
ls -l /dev/tpm*

```
# 1. Update your package lists and install the Clevis toolset
sudo apt update
sudo apt install clevis clevis-tpm2 clevis-luks clevis-initramfs

# 2. Bind your LUKS partition to the TPM (specifying sha256 to prevent errors)
sudo clevis luks bind -d /dev/nvme0n1p3 tpm2 '{"pcr_bank":"sha256","pcr_ids":"1,4,7"}'

# 3. Rebuild the boot image so the Clevis decryption hooks load during early boot
sudo update-initramfs -u -k all
```

reboot

Tpm2

2026-07-30T22:22:57Z

Busk: Created page with "Ubuntu 24.04 ls -l /dev/tpm* sudo apt install libtss2-rc0t64 libtss2-esys-3.0.2-0t64 tpm2-tools systemd-cryptenroll --tpm2-device=list lsblk -f | grep -i luk sudo systemd-cryp..."

Ubuntu 24.04
ls -l /dev/tpm*
sudo apt install libtss2-rc0t64 libtss2-esys-3.0.2-0t64 tpm2-tools
systemd-cryptenroll --tpm2-device=list
lsblk -f | grep -i luk
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=1+4+7 /dev/nvme0n1p3
sudo reboot
sudo update-initramfs -u -k all

Codex gemini install cli

2026-07-26T02:01:05Z

Busk:

# Debian/Ubuntu

```
sudo apt-get remove -y nodejs npm
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt-get install -y nodejs

mkdir -p ~/.npm-global
npm config set prefix '~/.npm-global'
export PATH=~/.npm-global/bin:$PATH
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.bashrc

npm install -g npm@latest
npm install -g --allow-scripts=@github/keytar,node-pty @openai/codex @google/gemini-cli

codex --version
gemini --version
```

Codex gemini install cli

2026-07-26T01:57:23Z

Busk:

# Debian/Ubuntu

```
sudo apt-get remove -y nodejs npm
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt-get install -y nodejs
sudo npm install -g npm@latest
sudo npm install -g npm@latest @openai/codex @google/gemini-cli
codex --version
gemini --version
```

Kubectl sniff

2026-07-25T21:16:09Z

Busk: Created page with "kubectl debug -i my-container-77c5f975d8-mt7mm -n my-ns --image=nicolaka/netshoot --target=my-container --profile=netadmin -- tcpdump -i any -nn -A -s 0 'tcp port 8080'..."

kubectl debug -i my-container-77c5f975d8-mt7mm -n my-ns --image=nicolaka/netshoot --target=my-container --profile=netadmin -- tcpdump -i any -nn -A -s 0 'tcp port 8080' | grep -iE 'X-Forwarded-For|Host:'

Cka kubeadm init upgrade

2026-07-24T17:30:10Z

Busk:

## Prep Ubuntu 24.04 & 22.04 Node

```
#!/bin/bash
set -eu

k8s_minor_version=1.31

prep_k8s_node(){
sudo apt update && sudo apt upgrade -y
sudo apt install apt-transport-https curl -y

# https://kubernetes.io/docs/setup/production-environment/container-runtimes/
sudo apt install containerd -y
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml > /dev/null
# Instruct containerd to use the Systemd cgroup hierarchy (typically cgroupv2) for managing container resources.
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
sudo systemctl restart containerd
echo "net.ipv4.ip_forward = 1" | /etc/sysctl.d/k8s.conf
sudo sysctl --system

# https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl
curl -fsSL https://pkgs.k8s.io/core:/stable:/v${k8s_minor_version}/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v${k8s_minor_version}/deb/ /" | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt update
sudo apt install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

swapon -s # returns summary text if swap is enabled
sudo swapoff -a
sudo sed -i '/ swap / s/^$.*$$/#\1/g' /etc/fstab

# overlay is already modprobed by containerd
sudo modprobe br_netfilter
echo -e "br_netfilter" | sudo tee /etc/modules-load.d/k8s.conf
lsmod | grep overlay
lsmod | grep br_netfilter

echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bashrc
sudo reboot
}

prep_k8s_node
```

## Install kubeadm kubectl kubelet

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl

```
sudo apt-get update
# apt-transport-https may be a dummy package; if so, you can skip that package
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

# If the directory `/etc/apt/keyrings` does not exist, it should be created before the curl command, read the note below.
# sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.32/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

# This overwrites any existing configuration in /etc/apt/sources.list.d/kubernetes.list
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.32/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
```

## Init Control Plane

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#initializing-your-control-plane-node

HA with LB for control see - https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/ - --control-plane-endpoint

```
kubeadm init --apiserver-advertise-address <local ip>

```

## Cilium

This is only needed on one node in the cluster for admin functions if wanted as helm is what installs cilium agent on k8s nodes

https://kubernetes.io/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/

```
https://kubernetes.io/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
rm cilium-linux-amd64.tar.gz
cilium install && cilium wait status
```

## Join worker node
```
kubeadm join
```

## Enable metrics-server api for kubectl top node

```
helm search hub metrics-server -o yaml
helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm install metrics-server metrics-server/metrics-server --set args[0]='--kubelet-insecure-tls'
```

Docker install ubuntu

2026-07-15T17:05:45Z

Busk: Created page with "``` sudo apt update sudo apt install -y ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /..."

```
sudo apt update
sudo apt install -y ca-certificates curl gnupg

sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
```

Lxc launch

2026-07-15T17:00:03Z

Busk:

lxc launch images:debian/11 bullseye-vm --vm

```
lxc --target lxdnode1 init ubuntu:22.04 --vm -c limits.cpu=6 -c limits.memory=12GB docker
lxc config device override docker root size=100GB
lxc start docker
```

lxc launch images:debian/11 docker-server --vm -c limits.cpu=4 -c limits.memory=12GiB -d root,size=50GiB

```
s. Assumptions: 1) One zfs pool called ‘default’ that lives on the hard drive at /var/lib/lxd/disks/default.img. 2) Running as root. 3) Growing pool ‘default’ from 25GB to 45GB. Stop all running containers. #truncate -s +20G /var/lib/lxd/disks/default.img #zpool set autoexpand=on default #zpool status -vg default 4a. Note th…
```

```
lxc init images:ubuntu/focal ${VM} -p default -p vm --vm
lxc config set ${VM} limits.cpu ${CPU}
lxc config set ${VM} limits.memory ${MEM}
lxc config device override ${VM} root size=${DISK}
lxc start ${VM}
```

# Centos7
```
lxc launch images:centos/7/amd64 centos7
```

Envoy from nginx for ingress

2026-06-22T05:29:40Z

Busk:

go install github.com/kubernetes-sigs/ingress2gateway@latest

# Translate an existing NGINX ingress into Gateway API manifests
ingress2gateway print --providers ingress-nginx > new-envoy-routes.yaml

ingress-to-envoy-gateway.sh
```
#!/usr/bin/env bash
set -euo pipefail

usage() {
cat <<'USAGE'
Usage:
scripts/ingress-to-envoy-gateway.sh -n NAMESPACE INGRESS [options]

Converts one Kubernetes Ingress into Gateway API resources for Envoy Gateway.
By default the script prints YAML. Use --apply to apply it.

Options:
--gateway NAME Gateway name. Default: INGRESS-gateway
--gateway-namespace NAMESPACE Gateway namespace. Default: Ingress namespace
--use-existing-gateway Do not emit a Gateway; attach routes to --gateway
--gateway-class NAME GatewayClass name. Default: eg
--issuer NAME ClusterIssuer name for generated Certificates. Default: letsencrypt-prod
--emit-certificate Emit cert-manager Certificate resources for Ingress TLS secrets.
With --use-existing-gateway, Certificates are emitted in
the Gateway namespace and --apply patches the Gateway
HTTPS listener certificateRefs.
--force-tls Route to the HTTPS listener even if the Ingress has no TLS block
--tls-secret NAME TLS Secret/Certificate name to use with --force-tls
--backend-tls none|system|ca Handle nginx backend-protocol=HTTPS. Default: none
--backend-tls-hostname NAME SNI/validation hostname for BackendTLSPolicy. Default: first Ingress host
--backend-tls-ca-configmap NAME
ConfigMap with ca.crt when --backend-tls=ca
--apply Apply generated YAML instead of printing it
-h, --help Show this help

Examples:
# Preview conversion for uapp/ucontrol-ui.
scripts/ingress-to-envoy-gateway.sh -n uapp ucontrol-ui --backend-tls system

# Apply conversion.
scripts/ingress-to-envoy-gateway.sh -n uapp ucontrol-ui --backend-tls system --apply

# Attach uapp/ucontrol-ui to an existing central Gateway.
scripts/ingress-to-envoy-gateway.sh -n uapp ucontrol-ui \
--use-existing-gateway \
--gateway default-gateway \
--gateway-namespace example-io \
--backend-tls system

Notes:
- The original Ingress is not changed or deleted.
- DNS must be moved to the new Envoy Gateway IP after verification.
- nginx.ingress.kubernetes.io/backend-protocol=HTTPS requires BackendTLSPolicy.
Use --backend-tls system for publicly trusted backend certs, or --backend-tls ca
with --backend-tls-ca-configmap for private CAs.
USAGE
}

die() {
printf 'error: %s\n' "$*" >&2
exit 1
}

need() {
command -v "$1" >/dev/null 2>&1 || die "missing required command: $1"
}

default_kubectl() {
if [[ -x /snap/kubectl/current/kubectl ]]; then
printf '%s\n' /snap/kubectl/current/kubectl
else
printf '%s\n' kubectl
fi
}

yaml_quote() {
printf '%s' "$1" | sed "s/'/''/g; s/^/'/; s/$/'/"
}

resource_name() {
printf '%s' "$1" | tr '[:upper:]' '[:lower:]' | sed -E 's/[^a-z0-9.-]+/-/g; s/^-+//; s/-+$//' | cut -c1-63
}

resolve_service_port() {
local svc="$1"
local port_name="$2"

"$kubectl_cmd" get svc -n "$namespace" "$svc" -o json |
jq -r --arg name "$port_name" '
.spec.ports[] | select(.name == $name) | .port
' | head -n 1
}

gateway_has_cert_ref() {
local secret="$1"

"$kubectl_cmd" get gateway -n "$gateway_namespace" "$gateway" -o json |
jq -e --arg secret "$secret" '
.spec.listeners[]
| select(.name == "https")
| (.tls.certificateRefs // [])
| any(.name == $secret)
' >/dev/null
}

patch_gateway_cert_ref() {
local secret="$1"

if gateway_has_cert_ref "$secret"; then
printf 'Gateway %s/%s already references TLS secret %s\n' "$gateway_namespace" "$gateway" "$secret" >&2
return
fi

"$kubectl_cmd" patch gateway "$gateway" -n "$gateway_namespace" --type json \
-p="[{\"op\":\"add\",\"path\":\"/spec/listeners/1/tls/certificateRefs/-\",\"value\":{\"name\":\"$secret\"}}]"
}

namespace=""
ingress=""
gateway=""
gateway_namespace=""
create_gateway="true"
gateway_class="eg"
issuer="letsencrypt-prod"
emit_certificate="false"
backend_tls="none"
backend_tls_hostname=""
backend_tls_ca_configmap=""
force_tls="false"
tls_secret_override=""
apply="false"
kubectl_cmd="${KUBECTL:-$(default_kubectl)}"

while [[ $# -gt 0 ]]; do
case "$1" in
-n|--namespace)
namespace="${2:-}"
shift 2
;;
--gateway)
gateway="${2:-}"
shift 2
;;
--gateway-namespace)
gateway_namespace="${2:-}"
shift 2
;;
--use-existing-gateway)
create_gateway="false"
shift
;;
--gateway-class)
gateway_class="${2:-}"
shift 2
;;
--issuer)
issuer="${2:-}"
shift 2
;;
--emit-certificate)
emit_certificate="true"
shift
;;
--force-tls)
force_tls="true"
shift
;;
--tls-secret)
tls_secret_override="${2:-}"
shift 2
;;
--backend-tls)
backend_tls="${2:-}"
shift 2
;;
--backend-tls-hostname)
backend_tls_hostname="${2:-}"
shift 2
;;
--backend-tls-ca-configmap)
backend_tls_ca_configmap="${2:-}"
shift 2
;;
--apply)
apply="true"
shift
;;
-h|--help)
usage
exit 0
;;
-*)
die "unknown option: $1"
;;
*)
if [[ -n "$ingress" ]]; then
die "unexpected extra argument: $1"
fi
ingress="$1"
shift
;;
esac
done

[[ -n "$namespace" ]] || die "namespace is required"
[[ -n "$ingress" ]] || die "ingress name is required"
case "$backend_tls" in
none|system|ca) ;;
*) die "--backend-tls must be one of: none, system, ca" ;;
esac
if [[ "$backend_tls" == "ca" && -z "$backend_tls_ca_configmap" ]]; then
die "--backend-tls-ca-configmap is required when --backend-tls=ca"
fi
if [[ "$force_tls" == "true" && -z "$tls_secret_override" ]]; then
die "--tls-secret is required when --force-tls is set"
fi

need jq
need sed
need tr
need cut
need head
if [[ "$kubectl_cmd" == */* ]]; then
[[ -x "$kubectl_cmd" ]] || die "kubectl is not executable: $kubectl_cmd"
else
need "$kubectl_cmd"
fi

gateway="${gateway:-$(resource_name "${ingress}-gateway")}"
gateway_namespace="${gateway_namespace:-$namespace}"

ingress_json="$("$kubectl_cmd" get ingress -n "$namespace" "$ingress" -o json)"

mapfile -t hosts < <(jq -r '.spec.rules[]?.host // empty' <<<"$ingress_json" | awk 'NF' | sort -u)
[[ "${#hosts[@]}" -gt 0 ]] || die "Ingress has no host rules"

if [[ -z "$backend_tls_hostname" ]]; then
backend_tls_hostname="${hosts[0]}"
fi

mapfile -t tls_secrets < <(jq -r '.spec.tls[]?.secretName // empty' <<<"$ingress_json" | awk 'NF' | sort -u)
if [[ -n "$tls_secret_override" ]]; then
tls_secrets=("$tls_secret_override")
fi
has_tls="false"
if [[ "${#tls_secrets[@]}" -gt 0 || "$force_tls" == "true" ]]; then
has_tls="true"
fi
if [[ "$create_gateway" == "false" && "$has_tls" == "true" ]]; then
emit_certificate="true"
fi

ssl_redirect="$(
jq -r '
.metadata.annotations["nginx.ingress.kubernetes.io/ssl-redirect"] //
.metadata.annotations["nginx.ingress.kubernetes.io/force-ssl-redirect"] //
"false"
' <<<"$ingress_json"
)"
backend_protocol="$(jq -r '.metadata.annotations["nginx.ingress.kubernetes.io/backend-protocol"] // "HTTP"' <<<"$ingress_json" | tr '[:lower:]' '[:upper:]')"

if [[ "$backend_protocol" == "HTTPS" && "$backend_tls" == "none" ]]; then
printf 'warning: %s/%s uses nginx backend-protocol=HTTPS; generated route will need BackendTLSPolicy or backend HTTP support.\n' "$namespace" "$ingress" >&2
fi

tmp="$(mktemp)"
trap 'rm -f "$tmp"' EXIT

{
if [[ "$create_gateway" == "true" ]]; then
cat <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: $gateway
namespace: $gateway_namespace
labels:
app.kubernetes.io/managed-by: ingress-to-envoy-gateway
app.kubernetes.io/source-ingress: $ingress
spec:
gatewayClassName: $gateway_class
listeners:
- name: http
port: 80
protocol: HTTP
allowedRoutes:
namespaces:
from: Same
EOF

if [[ "$has_tls" == "true" ]]; then
cat <<'EOF'
- name: https
port: 443
protocol: HTTPS
tls:
mode: Terminate
certificateRefs:
EOF
for secret in "${tls_secrets[@]}"; do
printf ' - name: %s\n' "$secret"
done
cat <<'EOF'
allowedRoutes:
namespaces:
from: Same
EOF
fi
printf '%s\n' '---'
fi

cat <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: $ingress
namespace: $namespace
labels:
app.kubernetes.io/managed-by: ingress-to-envoy-gateway
app.kubernetes.io/source-ingress: $ingress
spec:
hostnames:
EOF
for host in "${hosts[@]}"; do
printf ' - %s\n' "$(yaml_quote "$host")"
done
cat <<EOF
parentRefs:
- name: $gateway
namespace: $gateway_namespace
sectionName: $([[ "$has_tls" == "true" ]] && printf 'https' || printf 'http')
rules:
EOF

route_count="$(jq '[.spec.rules[]?.http.paths[]?] | length' <<<"$ingress_json")"
[[ "$route_count" != "0" ]] || die "Ingress has no HTTP paths"

for i in $(seq 0 "$((route_count - 1))"); do
item="$(jq -c "[.spec.rules[]?.http.paths[]?][$i]" <<<"$ingress_json")"
path="$(jq -r '.path // "/"' <<<"$item")"
path_type="$(jq -r '.pathType // "Prefix"' <<<"$item")"
svc="$(jq -r '.backend.service.name // empty' <<<"$item")"
port_number="$(jq -r '.backend.service.port.number // empty' <<<"$item")"
port_name="$(jq -r '.backend.service.port.name // empty' <<<"$item")"

[[ -n "$svc" ]] || die "path $i has no Service backend"
if [[ -z "$port_number" && -n "$port_name" ]]; then
port_number="$(resolve_service_port "$svc" "$port_name")"
[[ -n "$port_number" ]] || die "could not resolve named port $svc/$port_name"
fi
[[ -n "$port_number" ]] || die "path $i has no Service port"

case "$path_type" in
Prefix) gateway_path_type="PathPrefix" ;;
Exact) gateway_path_type="Exact" ;;
ImplementationSpecific) gateway_path_type="PathPrefix" ;;
*) gateway_path_type="PathPrefix" ;;
esac

cat <<EOF
- matches:
- path:
type: $gateway_path_type
value: $(yaml_quote "$path")
backendRefs:
- name: $svc
port: $port_number
EOF
done

if [[ "$has_tls" == "true" ]] && { [[ "$ssl_redirect" == "true" ]] || [[ "$force_tls" == "true" ]]; }; then
cat <<EOF
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: $(resource_name "${ingress}-https-redirect")
namespace: $namespace
labels:
app.kubernetes.io/managed-by: ingress-to-envoy-gateway
app.kubernetes.io/source-ingress: $ingress
spec:
hostnames:
EOF
for host in "${hosts[@]}"; do
printf ' - %s\n' "$(yaml_quote "$host")"
done
cat <<EOF
parentRefs:
- name: $gateway
namespace: $gateway_namespace
sectionName: http
rules:
- filters:
- type: RequestRedirect
requestRedirect:
scheme: https
statusCode: 301
matches:
- path:
type: PathPrefix
value: /
EOF
fi

if [[ "$backend_protocol" == "HTTPS" && "$backend_tls" != "none" ]]; then
mapfile -t https_services < <(
jq -r '.spec.rules[]?.http.paths[]?.backend.service.name // empty' <<<"$ingress_json" |
awk 'NF' | sort -u
)
for svc in "${https_services[@]}"; do
cat <<EOF
---
apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
name: $(resource_name "${ingress}-${svc}-backend-tls")
namespace: $namespace
labels:
app.kubernetes.io/managed-by: ingress-to-envoy-gateway
app.kubernetes.io/source-ingress: $ingress
spec:
targetRefs:
- group: ""
kind: Service
name: $svc
validation:
hostname: $(yaml_quote "$backend_tls_hostname")
EOF
if [[ "$backend_tls" == "system" ]]; then
cat <<'EOF'
wellKnownCACertificates: System
EOF
else
cat <<EOF
caCertificateRefs:
- group: ""
kind: ConfigMap
name: $backend_tls_ca_configmap
EOF
fi
done
fi

if [[ "$emit_certificate" == "true" && "$has_tls" == "true" ]]; then
for secret in "${tls_secrets[@]}"; do
mapfile -t cert_hosts < <(
jq -r --arg secret "$secret" '
.spec.tls[]? | select(.secretName == $secret) | .hosts[]?
' <<<"$ingress_json" | awk 'NF' | sort -u
)
[[ "${#cert_hosts[@]}" -gt 0 ]] || cert_hosts=("${hosts[@]}")
cat <<EOF
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: $secret
namespace: $([[ "$create_gateway" == "false" ]] && printf '%s' "$gateway_namespace" || printf '%s' "$namespace")
labels:
app.kubernetes.io/managed-by: ingress-to-envoy-gateway
app.kubernetes.io/source-ingress: $ingress
spec:
secretName: $secret
dnsNames:
EOF
for host in "${cert_hosts[@]}"; do
printf ' - %s\n' "$(yaml_quote "$host")"
done
cat <<EOF
issuerRef:
group: cert-manager.io
kind: ClusterIssuer
name: $issuer
EOF
done
fi
} >"$tmp"

if [[ "$apply" == "true" ]]; then
"$kubectl_cmd" apply -f "$tmp"
if [[ "$create_gateway" == "false" && "$has_tls" == "true" ]]; then
for secret in "${tls_secrets[@]}"; do
patch_gateway_cert_ref "$secret"
done
fi
else
cat "$tmp"
fi
```

Envoy from nginx for ingress

2026-06-22T02:18:10Z

Busk: Created page with "go install github.com/kubernetes-sigs/ingress2gateway@latest # Translate an existing NGINX ingress into Gateway API manifests ingress2gateway print --providers ingress-nginx..."

go install github.com/kubernetes-sigs/ingress2gateway@latest

# Translate an existing NGINX ingress into Gateway API manifests
ingress2gateway print --providers ingress-nginx > new-envoy-routes.yaml

AI notes

2026-06-20T10:24:51Z

Busk: Created page with "https://youtu.be/sOPDGQjFcuM?is=pGCLuNECaFYHC2xa"

https://youtu.be/sOPDGQjFcuM?is=pGCLuNECaFYHC2xa

Docker install

2026-06-19T23:10:20Z

Busk:

# Install

## Ubuntu Docker-CE Install using zfs for data mount
```
#!/bin/bash

set -e

DATASET_NAME="tank-nvme/docker"
DOCKER_DIR="/var/lib/docker"

if ! sudo zfs list "${DATASET_NAME%%/*}" &>/dev/null; then
echo "Error: ZFS pool '${DATASET_NAME%%/*}' does not exist." >&2
exit 1
fi

if sudo zfs list "$DATASET_NAME" &>/dev/null; then
echo "ZFS dataset $DATASET_NAME already exists."
else
sudo zfs create -o mountpoint=legacy "$DATASET_NAME"
fi

# Add Docker's official GPG key:
sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

sudo systemctl stop docker
sudo systemctl stop docker.socket

sudo mkdir -p "$DOCKER_DIR"

if ! mountpoint -q "$DOCKER_DIR"; then
sudo mount -t zfs "$DATASET_NAME" "$DOCKER_DIR"
fi

if ! grep -q "$DATASET_NAME" /etc/fstab; then
echo "$DATASET_NAME $DOCKER_DIR zfs defaults 0 0" | sudo tee -a /etc/fstab > /dev/null
fi

sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json > /dev/null <<EOF
{
"storage-driver": "zfs"
}
EOF

sudo systemctl start docker
sleep 5
sudo docker run hello-world
```

Docker install

2026-06-19T23:08:21Z

Busk:

# Install

## Ubuntu Install using zfs for data
```
#!/bin/bash

set -e

DATASET_NAME="tank-nvme/docker"
DOCKER_DIR="/var/lib/docker"

if ! sudo zfs list "${DATASET_NAME%%/*}" &>/dev/null; then
echo "Error: ZFS pool '${DATASET_NAME%%/*}' does not exist." >&2
exit 1
fi

if sudo zfs list "$DATASET_NAME" &>/dev/null; then
echo "ZFS dataset $DATASET_NAME already exists."
else
sudo zfs create -o mountpoint=legacy "$DATASET_NAME"
fi

# Add Docker's official GPG key:
sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

sudo systemctl stop docker
sudo systemctl stop docker.socket

sudo mkdir -p "$DOCKER_DIR"

if ! mountpoint -q "$DOCKER_DIR"; then
sudo mount -t zfs "$DATASET_NAME" "$DOCKER_DIR"
fi

if ! grep -q "$DATASET_NAME" /etc/fstab; then
echo "$DATASET_NAME $DOCKER_DIR zfs defaults 0 0" | sudo tee -a /etc/fstab > /dev/null
fi

sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json > /dev/null <<EOF
{
"storage-driver": "zfs"
}
EOF

sudo systemctl start docker
sleep 5
sudo docker run hello-world
```

Docker install

2026-06-19T23:07:23Z

Busk:

#!/bin/bash

set -e

DATASET_NAME="tank-nvme/docker"
DOCKER_DIR="/var/lib/docker"

if ! sudo zfs list "${DATASET_NAME%%/*}" &>/dev/null; then
echo "Error: ZFS pool '${DATASET_NAME%%/*}' does not exist." >&2
exit 1
fi

if sudo zfs list "$DATASET_NAME" &>/dev/null; then
echo "ZFS dataset $DATASET_NAME already exists."
else
sudo zfs create -o mountpoint=legacy "$DATASET_NAME"
fi

# Add Docker's official GPG key:
sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

sudo systemctl stop docker
sudo systemctl stop docker.socket

sudo mkdir -p "$DOCKER_DIR"

if ! mountpoint -q "$DOCKER_DIR"; then
sudo mount -t zfs "$DATASET_NAME" "$DOCKER_DIR"
fi

if ! grep -q "$DATASET_NAME" /etc/fstab; then
echo "$DATASET_NAME $DOCKER_DIR zfs defaults 0 0" | sudo tee -a /etc/fstab > /dev/null
fi

sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json > /dev/null <<EOF
{
"storage-driver": "zfs"
}
EOF

sudo systemctl start docker
sleep 5
sudo docker run hello-world
```

Zfs pool

2026-06-15T21:46:57Z

Busk:

```
sudo zpool create -o ashift=12 tank-nvme mirror /dev/disk/by-id/nvme-eui.0025385281b1b872 /dev/disk/by-id/nvme-eui.0025385281b1b878

sudo wipefs -a /dev/disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3X3NF0K204029J
sudo wipefs -a /dev/disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3X3NF0K204035E

sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RMS
sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RPX
sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN0339T
sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RFB

sudo zpool create -o ashift=12 tank-hdd mirror /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RMS /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RPX mirror /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN0339T /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RFB
```

sudo zfs create -o atime=off -o compression=lz4 -o xattr=sa -o acltype=posixacl tank-nvme/lxd

## ashift

`ashift` stands for **alignment shift**. It dictates the minimum block size ZFS will use when formatting and writing data to the physical storage devices in your pool.

The number you provide is an exponent of 2:

* `ashift=9` means $2^9=512$ bytes.
* `ashift=12` means $2^{12}=4096$ bytes (4K).
* `ashift=13` means $2^{13}=8192$ bytes (8K).

Here is why forcing `ashift=12` is critical for modern storage.

### **The 512-byte Lie (Emulation)**

Historically, hard drives used physical sectors that were exactly 512 bytes in size. However, almost all modern hard drives and SSDs use **Advanced Format**, meaning their physical layout is built on 4096-byte (4K) sectors. This larger size allows for higher storage density and better error correction.

To avoid breaking older operating systems and legacy hardware controllers, many modern 4K drives "lie" to the host system. They use a firmware feature called **512e (512-byte emulation)** to report themselves as having old-school 512-byte sectors, even though their physical architecture is 4K.

### **The Read-Modify-Write Penalty**

If you create a ZFS pool without specifying the `ashift` value, ZFS will often interrogate the drive, hear the 512-byte lie, and set `ashift=9`. This creates a severe misalignment between ZFS's logical blocks and the drive's physical sectors.

If ZFS attempts to write a 512-byte block to a physical 4K sector, the storage drive is forced to execute a **Read-Modify-Write** operation:

1. **Read:** The drive reads the entire 4K physical sector into its internal memory.
2. **Modify:** The drive inserts the 512 bytes ZFS sent into the 4K block.
3. **Write:** The drive writes the whole 4K sector back to the disk.

This massive overhead completely destroys write performance (especially random I/O) and causes severe "write amplification," which prematurely burns through the endurance limits of NVMe and SSD drives.

### **The Solution**

By explicitly appending `-o ashift=12` to your `zpool create` command, you force ZFS to align all of its data payloads to exact 4K boundaries. This ensures ZFS writes map perfectly to the physical hardware beneath it, entirely bypassing the emulation penalty and ensuring optimal throughput and drive lifespan.

> **Note:** The `ashift` value is permanently baked into a top-level virtual device (vdev) at the moment of creation. If you create a pool with the wrong `ashift`, it cannot be changed later; you have to destroy the pool, wipe the drives, and start over.

Zfs pool

2026-06-15T20:56:16Z

Busk:

```
sudo zpool create -o ashift=12 tank-nvme mirror /dev/disk/by-id/nvme-eui.0025385281b1b872 /dev/disk/by-id/nvme-eui.0025385281b1b878

sudo wipefs -a /dev/disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3X3NF0K204029J
sudo wipefs -a /dev/disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3X3NF0K204035E

sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RMS
sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RPX
sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN0339T
sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RFB

sudo zpool create -o ashift=12 tank-hdd mirror /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RMS /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RPX mirror /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN0339T /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RFB
```

## ashift

`ashift` stands for **alignment shift**. It dictates the minimum block size ZFS will use when formatting and writing data to the physical storage devices in your pool.

The number you provide is an exponent of 2:

* `ashift=9` means $2^9=512$ bytes.
* `ashift=12` means $2^{12}=4096$ bytes (4K).
* `ashift=13` means $2^{13}=8192$ bytes (8K).

Here is why forcing `ashift=12` is critical for modern storage.

### **The 512-byte Lie (Emulation)**

Historically, hard drives used physical sectors that were exactly 512 bytes in size. However, almost all modern hard drives and SSDs use **Advanced Format**, meaning their physical layout is built on 4096-byte (4K) sectors. This larger size allows for higher storage density and better error correction.

To avoid breaking older operating systems and legacy hardware controllers, many modern 4K drives "lie" to the host system. They use a firmware feature called **512e (512-byte emulation)** to report themselves as having old-school 512-byte sectors, even though their physical architecture is 4K.

### **The Read-Modify-Write Penalty**

If you create a ZFS pool without specifying the `ashift` value, ZFS will often interrogate the drive, hear the 512-byte lie, and set `ashift=9`. This creates a severe misalignment between ZFS's logical blocks and the drive's physical sectors.

If ZFS attempts to write a 512-byte block to a physical 4K sector, the storage drive is forced to execute a **Read-Modify-Write** operation:

1. **Read:** The drive reads the entire 4K physical sector into its internal memory.
2. **Modify:** The drive inserts the 512 bytes ZFS sent into the 4K block.
3. **Write:** The drive writes the whole 4K sector back to the disk.

This massive overhead completely destroys write performance (especially random I/O) and causes severe "write amplification," which prematurely burns through the endurance limits of NVMe and SSD drives.

### **The Solution**

By explicitly appending `-o ashift=12` to your `zpool create` command, you force ZFS to align all of its data payloads to exact 4K boundaries. This ensures ZFS writes map perfectly to the physical hardware beneath it, entirely bypassing the emulation penalty and ensuring optimal throughput and drive lifespan.

> **Note:** The `ashift` value is permanently baked into a top-level virtual device (vdev) at the moment of creation. If you create a pool with the wrong `ashift`, it cannot be changed later; you have to destroy the pool, wipe the drives, and start over.

Zfs pool

2026-06-15T20:52:51Z

Busk:

```
sudo zpool create -o ashift=12 tank-nvme mirror /dev/disk/by-id/nvme-eui.0025385281b1b872 /dev/disk/by-id/nvme-eui.0025385281b1b878

sudo wipefs -a /dev/disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3X3NF0K204029J
sudo wipefs -a /dev/disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3X3NF0K204035E

sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RMS
sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RPX
sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN0339T
sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RFB

sudo zpool create -o ashift=12 tank-hdd mirror /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RMS /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RPX mirror /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN0339T /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RFB
```

## ashift

ashift stands for alignment shift. It dictates the minimum block size ZFS will use when formatting and writing data to the physical storage devices in your pool.The number you provide is an exponent of 2:ashift=9 means $2^9=512$ bytes.ashift=12 means $2^{12}=4096$ bytes (4K).ashift=13 means $2^{13}=8192$ bytes (8K).Here is why forcing ashift=12 is critical for modern storage.The 512-byte Lie (Emulation)Historically, hard drives used physical sectors that were exactly 512 bytes in size. However, almost all modern hard drives and SSDs use Advanced Format, meaning their physical layout is built on 4096-byte (4K) sectors. This larger size allows for higher storage density and better error correction.To avoid breaking older operating systems and legacy hardware controllers, many modern 4K drives "lie" to the host system. They use a firmware feature called 512e (512-byte emulation) to report themselves as having old-school 512-byte sectors, even though their physical architecture is 4K.The Read-Modify-Write PenaltyIf you create a ZFS pool without specifying the ashift value, ZFS will often interrogate the drive, hear the 512-byte lie, and set ashift=9. This creates a severe misalignment between ZFS's logical blocks and the drive's physical sectors.If ZFS attempts to write a 512-byte block to a physical 4K sector, the storage drive is forced to execute a Read-Modify-Write operation:Read: The drive reads the entire 4K physical sector into its internal memory.Modify: The drive inserts the 512 bytes ZFS sent into the 4K block.Write: The drive writes the whole 4K sector back to the disk.This massive overhead completely destroys write performance (especially random I/O) and causes severe "write amplification," which prematurely burns through the endurance limits of NVMe and SSD drives.The SolutionBy explicitly appending -o ashift=12 to your zpool create command, you force ZFS to align all of its data payloads to exact 4K boundaries. This ensures ZFS writes map perfectly to the physical hardware beneath it, entirely bypassing the emulation penalty and ensuring optimal throughput and drive lifespan.Note: The ashift value is permanently baked into a top-level virtual device (vdev) at the moment of creation. If you create a pool with the wrong ashift, it cannot be changed later; you have to destroy the pool, wipe the drives, and start over.

Zfs pool

2026-06-15T20:47:33Z

Busk:

Zfs pool

2026-06-15T20:47:12Z

Busk: Created page with " ``` sudo zpool create -o ashift=12 tank1 mirror /dev/disk/by-id/nvme-eui.0025385281b1b872 /dev/disk/by-id/nvme-eui.0025385281b1b878 sudo wipefs -a /dev/disk/by-id/nvme-Samsu..."

```
sudo zpool create -o ashift=12 tank1 mirror /dev/disk/by-id/nvme-eui.0025385281b1b872 /dev/disk/by-id/nvme-eui.0025385281b1b878

sudo wipefs -a /dev/disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3X3NF0K204029J
sudo wipefs -a /dev/disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3X3NF0K204035E

sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RMS
sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RPX
sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN0339T
sudo wipefs -a /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RFB

sudo zpool create -o ashift=12 mypool mirror /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RMS /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RPX mirror /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN0339T /dev/disk/by-id/ata-ST4000DM004-2CV104_ZFN07RFB
```

Sandbox3

2026-06-07T00:35:27Z

Busk: Created page with "``` #!/bin/bash export REPO="your-owner/your-repo" export BRANCH="main" export RULESET_NAME="Migrated Protection - $BRANCH" # 1. Fetch Classic Branch Protection Rules echo "F..."

```
#!/bin/bash
export REPO="your-owner/your-repo"
export BRANCH="main"
export RULESET_NAME="Migrated Protection - $BRANCH"

# 1. Fetch Classic Branch Protection Rules
echo "Fetching classic branch protection for $BRANCH..."
CLASSIC_RULES=$(gh api repos/$REPO/branches/$BRANCH/protection -X GET 2>/dev/null)

if [ -z "$CLASSIC_RULES" ]; then
echo "No classic rules found or error accessing repo."
exit 1
fi

# 2. Extract and Map Protections
REQ_PR=$(echo "$CLASSIC_RULES" | jq -e '.required_pull_request_reviews' >/dev/null && echo "true" || echo "false")
REQ_APPROVALS=$(echo "$CLASSIC_RULES" | jq '.required_pull_request_reviews.required_approving_review_count // 1')
DISMISS_STALE=$(echo "$CLASSIC_RULES" | jq '.required_pull_request_reviews.dismiss_stale_reviews // false')
REQ_CODE_OWNERS=$(echo "$CLASSIC_RULES" | jq '.required_pull_request_reviews.require_code_owner_reviews // false')

REQ_CHECKS=$(echo "$CLASSIC_RULES" | jq -e '.required_status_checks' >/dev/null && echo "true" || echo "false")
REQ_STRICT=$(echo "$CLASSIC_RULES" | jq '.required_status_checks.strict // false')
CONTEXTS=$(echo "$CLASSIC_RULES" | jq '.required_status_checks.contexts // []')

ENFORCE_ADMINS=$(echo "$CLASSIC_RULES" | jq '.enforce_admins.enabled // false')
REQ_LINEAR=$(echo "$CLASSIC_RULES" | jq '.required_linear_history.enabled // false')
REQ_SIGNATURES=$(echo "$CLASSIC_RULES" | jq '.required_signatures.enabled // false')

# 3. Construct Ruleset Payload
PAYLOAD=$(jq -n \
--arg name "$RULESET_NAME" \
--arg target "$BRANCH" \
--argjson req_pr "$REQ_PR" \
--argjson approvals "$REQ_APPROVALS" \
--argjson dismiss_stale "$DISMISS_STALE" \
--argjson code_owners "$REQ_CODE_OWNERS" \
--argjson req_checks "$REQ_CHECKS" \
--argjson strict "$REQ_STRICT" \
--argjson contexts "$CONTEXTS" \
--argjson linear "$REQ_LINEAR" \
--argjson signatures "$REQ_SIGNATURES" \
'
{
"name": $name,
"target": "branch",
"enforcement": "active",
"conditions": {
"ref_name": {
"include": ["refs/heads/" + $target],
"exclude": []
}
},
"rules": [
{ "type": "deletion" },
{ "type": "non_fast_forward" }
]
}
| if $req_pr then .rules += [{
"type": "pull_request",
"parameters": {
"required_approving_review_count": $approvals,
"dismiss_stale_reviews_on_push": $dismiss_stale,
"require_code_owner_review": $code_owners,
"require_last_push_approval": false
}
}] else . end
| if $req_checks then .rules += [{
"type": "required_status_checks",
"parameters": {
"strict_required_status_checks_policy": $strict,
"required_status_checks": ($contexts | map({ context: ., integration_id: 0 }))
}
}] else . end
| if $linear then .rules += [{ "type": "required_linear_history" }] else . end
| if $signatures then .rules += [{ "type": "required_signatures" }] else . end
')

# 4. Create the New Ruleset
echo "Creating new Branch Ruleset..."
CREATE_RES=$(gh api repos/$REPO/rulesets -X POST --input - <<< "$PAYLOAD")

if [ $? -eq 0 ]; then
echo "Ruleset successfully created!"

# 5. Optional: Delete the classic rule if the ruleset succeeded
echo "To complete the migration, manually delete the classic rule or uncomment the line below:"
echo "# gh api repos/$REPO/branches/$BRANCH/protection -X DELETE"
else
echo "Failed to create ruleset."
fi
```

Sed

2026-06-03T20:07:09Z

Busk:

https://opensource.com/article/20/12/sed

grep -rl oldtext . | xargs sed -i 's/oldtext/newtext/g'

find . -type f -name "*.txt" -exec sed -i 's/old_text/new_text/g' {} +

find . -type f -name "*.txt" -exec sed -i '' 's/old_text/new_text/g' {} +

find . -type f -name "*.txt" -print0 | xargs -0 sed -i 's/old_text/new_text/g'v

## Linux

grep -rlZ --exclude-dir='.git' 'oldtext' . | xargs -0 sed -i 's/oldtext/newtext/g'

## Macos/freebsd
grep -rl --null --exclude-dir='.git' 'oldtext' . | xargs -0 sed -i '' 's/oldtext/newtext/g'

Sed

2026-06-03T20:05:29Z

Busk:

Hugo

2026-06-01T15:07:51Z

Busk: Created page with "``` nohup hugo server --source website_hugo --disableFastRender > hugo-server.log 2>&1 & ```"

```
nohup hugo server --source website_hugo --disableFastRender > hugo-server.log 2>&1 &
```

Rsync

2026-05-31T22:35:42Z

Busk:

# Backup Command

rsync -axSH --exclude='.locks/' --dry-run --progress ~/.cache/huggingface/hub/ /ai/hf_cache/hub/

rate limit 10000 Kbytes per second on zfs
```
sudo zfs create -o mountpoint=/bkp zfspv-pool/bkp
sudo adduser bkp
sudo chown bkp:bkp /bkp
rsync -avz --recursive --bwlimit=10000 --exclude "hourly." --relative -e "ssh -p 22 -l bkp" --progress /var/lib/influxdb 10.x.x.x:/bkp/myinfluxbkp
```

Backup example
```
rsync -avzSuc --recursive --relative --delete -e "ssh -p 22 -i /home/user/.ssh/id_ed25519" --progress --files-from=files.dat / user@10.x.x.x:/home/busk/rsync --include-from=includes.dat --exclude-from=excludes.dat
```

Use lxd container and lxc snapshots to manage state. You can use rdiff-backup command tool as well

```
sudo rsync --dry-run -rv -e "ssh -p 22 -i /home/myuser/.ssh/id_ed25519" --rsync-path="sudo rsyn
c" myuser@10.x.x.x:/bkp/foo /docker/
```

Rsync

2026-05-31T22:33:41Z

Busk:

# Backup Command

rsync -axSH --dry-run --progress ~/.cache/huggingface/hub/ /ai/hf_cache/hub/

rate limit 10000 Kbytes per second on zfs
```
sudo zfs create -o mountpoint=/bkp zfspv-pool/bkp
sudo adduser bkp
sudo chown bkp:bkp /bkp
rsync -avz --recursive --bwlimit=10000 --exclude "hourly." --relative -e "ssh -p 22 -l bkp" --progress /var/lib/influxdb 10.x.x.x:/bkp/myinfluxbkp
```

Backup example
```
rsync -avzSuc --recursive --relative --delete -e "ssh -p 22 -i /home/user/.ssh/id_ed25519" --progress --files-from=files.dat / user@10.x.x.x:/home/busk/rsync --include-from=includes.dat --exclude-from=excludes.dat
```

Use lxd container and lxc snapshots to manage state. You can use rdiff-backup command tool as well

```
sudo rsync --dry-run -rv -e "ssh -p 22 -i /home/myuser/.ssh/id_ed25519" --rsync-path="sudo rsyn
c" myuser@10.x.x.x:/bkp/foo /docker/
```

Amdgpu rocm

2026-05-26T02:27:30Z

Busk:

# Make sure keyring dir exists
sudo mkdir --parents --mode=0755 /etc/apt/keyrings

# Refresh AMD key, same as you already did
wget https://repo.radeon.com/rocm/rocm.gpg.key -O - | \
gpg --dearmor | sudo tee /etc/apt/keyrings/rocm.gpg > /dev/null

# Add the missing AMDGPU kernel-driver repo for Ubuntu 24.04 / noble
sudo tee /etc/apt/sources.list.d/amdgpu.list > /dev/null <<'EOF'
deb [arch=amd64 signed-by=/etc/apt/keyrings/rocm.gpg] https://repo.radeon.com/amdgpu/30.30.3/ubuntu noble main
EOF

sudo apt update

# Confirm apt now sees it
apt-cache policy amdgpu-dkms

# Install prerequisites + driver
sudo apt install "linux-headers-$(uname -r)" "linux-modules-extra-$(uname -r)"
sudo apt install amdgpu-dkms

# Add yourself for ROCm access, then reboot
sudo usermod -a -G render,video "$LOGNAME"
sudo reboot

# Test
```
dkms status | grep -i amdgpu
lsmod | grep amdgpu
ls /dev/kfd /dev/dri/render*
rocminfo | head
amd-smi list
```

Amdgpu rocm

2026-05-26T02:23:14Z

Busk: Created page with "# Make sure keyring dir exists sudo mkdir --parents --mode=0755 /etc/apt/keyrings # Refresh AMD key, same as you already did wget https://repo.radeon.com/rocm/rocm.gpg.key -O..."

Rocm

2026-05-26T02:04:13Z

Busk: Created page with "https://rocm.docs.amd.com/projects/install-on-linux/en/latest/install/install-methods/package-manager/package-manager-ubuntu.html"

https://rocm.docs.amd.com/projects/install-on-linux/en/latest/install/install-methods/package-manager/package-manager-ubuntu.html

Zfs optimization

2026-05-25T15:56:52Z

Busk: Created page with "# ZFS Optimization Get & Set ## Get current settings for pool ``` #!/bin/bash if [ -z "$1" ]; then echo "Usage: $0 <pool_name>" exit 1 fi POOL="$1" if ! zpool list..."

# ZFS Optimization Get & Set

## Get current settings for pool
```
#!/bin/bash

if [ -z "$1" ]; then
echo "Usage: $0 <pool_name>"
exit 1
fi

POOL="$1"

if ! zpool list "$POOL" > /dev/null 2>&1; then
echo "Error: Pool '$POOL' does not exist."
exit 1
fi

echo "=== ZFS Pool Alignment ==="
zpool get ashift "$POOL"
echo ""

echo "=== Dataset Optimizations ==="
zfs get recordsize,atime,compression "$POOL"
echo ""

echo "=== TRIM Status ==="
zpool get autotrim "$POOL"
echo ""
zpool status -t "$POOL"
```

# Set optimization

```
#!/bin/bash

if [ -z "$1" ]; then
echo "Usage: $0 <pool_name>"
exit 1
fi

POOL="$1"

if ! zpool list "$POOL" > /dev/null 2>&1; then
echo "Error: Pool '$POOL' does not exist."
exit 1
fi

zfs set recordsize=1M "$POOL"
zfs set atime=off "$POOL"
zpool set autotrim=on "$POOL"

echo "Optimization settings applied to pool '$POOL'."
```

Codex use local openai api

2026-05-22T15:57:28Z

Busk: Created page with "To point the **Codex CLI** to your local `llama-server`, you primarily need to override the environment variables that the tool uses to locate the OpenAI API. Since the Codex..."

To point the **Codex CLI** to your local `llama-server`, you primarily need to override the environment variables that the tool uses to locate the OpenAI API.

Since the Codex CLI (and most OpenAI-compatible tools) follows standard OpenAI SDK conventions, you can redirect its traffic by pointing `OPENAI_BASE_URL` to your local endpoint.

### 1. Set the Environment Variables

You need to set these in your shell configuration (e.g., `~/.zshrc`, `~/.bashrc`) or for the specific session where you run the command.

* **`OPENAI_BASE_URL`**: Set this to your `llama-server` address, ensuring you include the `/v1` path.
* **`OPENAI_API_KEY`**: Even if your `llama-server` doesn't require authentication, the CLI usually expects this variable to exist. You can set it to any dummy string (e.g., `sk-no-key`).

**Example for your shell configuration:**

```bash
export OPENAI_BASE_URL="http://localhost:8080/v1"
export OPENAI_API_KEY="sk-not-needed"

```

*After saving this, run `source ~/.zshrc` (or your relevant shell config file) to apply the changes.*

---

### 2. Configure via `config.toml` (Optional/Permanent)

If you prefer a more permanent configuration—or if you need to use a specific model name that `llama-server` might not report by default—you can define a provider profile in the Codex CLI configuration file, typically located at `~/.codex/config.toml`.

Add a custom provider section like this:

```toml
# In ~/.codex/config.toml

[model_providers.local]
name = "Llama Server"
base_url = "http://localhost:8080/v1"
env_key = "OPENAI_API_KEY"

```

---

### 3. Verify the Connection

Once the environment variables are set, test the connection by running a simple command:

```bash
codex "What is the capital of Utah?"

```

### Important Tips for Local Models

* **Model Name:** If the CLI complains that the "model is not found," you may need to explicitly specify the model name that `llama-server` is reporting. You can check what models are available by hitting the `/v1/models` endpoint directly:
`curl http://localhost:8080/v1/models`
* **Compatibility:** Some "agentic" features of high-end CLI tools rely on OpenAI-specific function calling or vision capabilities. Depending on the model you are running in `llama.cpp` (e.g., a standard Llama 3 vs. a specialized coding model), some advanced agentic behaviors might have varying success compared to using a proprietary model like `gpt-4o`.
* **SSL/HTTPS:** Ensure your `llama-server` is running on `http` (or that you handle any certificate issues if you've enabled HTTPS), as CLI tools often fail with self-signed local certificates.

Zfs nvme log and cache

2026-05-22T15:42:26Z

Busk:

```
sudo nvme list
Node Generic SN Model Namespace Usage Format FW Rev
--------------------- --------------------- -------------------- ---------------------------------------- ---------- -------------------------- ---------------- --------
/dev/nvme0n1 /dev/ng0n1 CVFT439300062P0EGN INTEL SSDPEDMD020T4 0x1 2.00 TB / 2.00 TB 512 B + 0 B 8DV101H0

# 1. Create a new GPT partition table
sudo parted /dev/nvme0n1 mklabel gpt

# 2. Create the first 1TB partition (for SLOG)
sudo parted -a optimal /dev/nvme0n1 mkpart primary 0% 1TB

# 3. Create the second 1TB partition (for L2ARC)
sudo parted -a optimal /dev/nvme0n1 mkpart primary 1TB 100%

lsblk /dev/nvme0n1

# Add to log
sudo zpool add <pool_name> log /dev/nvme0n1p1

# Add to cache
sudo zpool add <pool_name> cache /dev/nvme0n1p2

```

# Removal & Size Updates

To change the size, you must remove the devices from the pool, repartition the drive, and add the new partitions back.

### The Removal Process

When you want to change the size, follow this sequence:

1. **Remove the log (SLOG) device:**
```bash
zpool remove <pool_name> /dev/nvme0n1p1

```

```
*Note: ZFS will gracefully flush any pending synchronous writes from the SLOG to the main pool before removing the device.*

2. **Remove the cache (L2ARC) device:**
```bash
zpool remove <pool_name> /dev/nvme0n1p2

```

```
*Note: This is instantaneous as it simply drops the cache.*

```

3. **Repartition the drive:**
Use `parted` or `fdisk` to delete the old partitions and create the new ones to your desired sizes.
4. **Add them back to the pool:**
```bash
zpool add <pool_name> log /dev/nvme0n1p1
zpool add <pool_name> cache /dev/nvme0n1p2

```

```

---

### Architect's Tip: Use LVM for Flexibility
If you anticipate wanting to resize these partitions later without wiping and recreating them, consider using **LVM (Logical Volume Manager)** as an intermediary layer.

1. Initialize the physical drive as an LVM Physical Volume (PV).
2. Create a Volume Group (VG).
3. Create two Logical Volumes (LV) — one for SLOG, one for L2ARC.
4. Point ZFS to the device-mapper paths (e.g., `/dev/mapper/vgname-lvname`).

**Why do this?**
* **Elasticity:** You can grow or shrink the logical volumes on the fly.
* **Abstraction:** You can move your ZFS log/cache to a different physical disk later by using `pvmove` without ever having to `zpool remove` or re-add the devices to ZFS.

**Important Warning:** If you go the LVM route, ensure you are not creating a circular dependency where your root filesystem (and thus LVM) depends on a ZFS pool that is trying to access an LVM volume. Given your expertise, this is likely a non-issue, but it is a common pitfall.

```

Zfs nvme log and cache

2026-05-22T15:42:11Z

Busk:

Zfs nvme log and cache

2026-05-22T15:36:45Z

Busk: Created page with "``` sudo nvme list Node Generic SN Model Namespace Usage Format..."

Llama optimization

2026-05-13T17:32:49Z

Busk: Created page with "Yes, that is a good **stable baseline**: ```bash ./build/bin/llama-server \ -hf ggml-org/gpt-oss-20b-GGUF \ -ngl 999 \ -c 2048 \ -np 1 \ -t 8 \ --no-warmup \ --..."

Yes, that is a good **stable baseline**:

```bash
./build/bin/llama-server \
-hf ggml-org/gpt-oss-20b-GGUF \
-ngl 999 \
-c 2048 \
-np 1 \
-t 8 \
--no-warmup \
--cache-ram 0 \
--host 0.0.0.0 \
--port 8080
```

For your **Threadripper + 128 GB RAM + Tesla P40**, I’d optimize for **stability first**, not max speed. Your previous log showed GPT-OSS 20B fully loaded, with the P40 detected as compute capability 6.1 and about 22.9 GiB VRAM available, so the hardware is basically working.

## My recommended P40-stable launcher

Use this instead:

```bash
cd ~/llama.cpp

GGML_CUDA_DISABLE_GRAPHS=1 ./build/bin/llama-server \
-hf ggml-org/gpt-oss-20b-GGUF \
-ngl 999 \
-c 2048 \
-np 1 \
-t 12 \
-b 512 \
-ub 256 \
--no-warmup \
--cache-ram 0 \
--host 0.0.0.0 \
--port 8080
```

Why:

```text
GGML_CUDA_DISABLE_GRAPHS=1 Avoids CUDA graph weirdness on older GPUs.
-c 2048 Lower context = lower KV/cache pressure.
-np 1 One request/slot at a time.
-t 12 Enough CPU threads without pegging Threadripper.
-b 512 -ub 256 Smaller batches; slower maybe, but less crashy.
--cache-ram 0 Avoids prompt cache save/load path that appeared near your crash.
--no-warmup Avoids extra startup GPU work.
```

CUDA graphs can improve performance, but they are also an area where llama.cpp has had CUDA-specific edge cases and workarounds; disabling them is a reasonable stability choice on Pascal/P40. NVIDIA’s CUDA-graphs writeup explains why they are used for performance, while llama.cpp issue/discussion threads show cases where disabling CUDA graphs is used as a workaround. ([NVIDIA Developer][1])

## Auto-detect launcher script

Create this:

```bash
cat > ~/run-llama-gpt-oss.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

MODEL_REPO="${MODEL_REPO:-ggml-org/gpt-oss-20b-GGUF}"
HOST="${HOST:-0.0.0.0}"
PORT="${PORT:-8080}"

# Detect CPU threads.
CPU_THREADS="$(nproc)"

# Use about half the CPU threads, capped. Good for responsiveness.
if (( CPU_THREADS >= 32 )); then
THREADS=12
elif (( CPU_THREADS >= 16 )); then
THREADS=8
else
THREADS=$(( CPU_THREADS / 2 ))
(( THREADS < 4 )) && THREADS=4
fi

# Detect system RAM in GiB.
RAM_GB="$(awk '/MemTotal/ { printf "%d", $2/1024/1024 }' /proc/meminfo)"

# Detect NVIDIA VRAM in MiB.
if command -v nvidia-smi >/dev/null 2>&1; then
VRAM_MIB="$(nvidia-smi --query-gpu=memory.total --format=csv,noheader,nounits | head -n1 | tr -d ' ')"
GPU_NAME="$(nvidia-smi --query-gpu=name --format=csv,noheader | head -n1)"
else
VRAM_MIB=0
GPU_NAME="none"
fi

# Conservative defaults for older GPUs.
CTX=2048
NP=1
BATCH=512
UBATCH=256
NGL=999
CACHE_RAM=0
NO_WARMUP="--no-warmup"
CUDA_ENV="GGML_CUDA_DISABLE_GRAPHS=1"

# If VRAM is very small, reduce context/batch.
if (( VRAM_MIB > 0 && VRAM_MIB < 16000 )); then
CTX=1024
BATCH=256
UBATCH=128
fi

# If VRAM is >= 32GB, allow larger context.
if (( VRAM_MIB >= 32000 )); then
CTX=4096
BATCH=1024
UBATCH=512
fi

# Detect Pascal/P40-ish GPU and keep safer settings.
if echo "$GPU_NAME" | grep -Eiq 'P40|P100|Pascal|GTX 10'; then
CTX=2048
NP=1
BATCH=512
UBATCH=256
CACHE_RAM=0
CUDA_ENV="GGML_CUDA_DISABLE_GRAPHS=1"
fi

echo "Detected:"
echo " CPU threads: $CPU_THREADS"
echo " RAM: ${RAM_GB} GiB"
echo " GPU: $GPU_NAME"
echo " VRAM: ${VRAM_MIB} MiB"
echo
echo "Launching llama-server:"
echo " model repo: $MODEL_REPO"
echo " ctx: $CTX"
echo " parallel: $NP"
echo " threads: $THREADS"
echo " batch: $BATCH"
echo " ubatch: $UBATCH"
echo " cache-ram: $CACHE_RAM"
echo

cd "$HOME/llama.cpp"

exec env $CUDA_ENV ./build/bin/llama-server \
-hf "$MODEL_REPO" \
-ngl "$NGL" \
-c "$CTX" \
-np "$NP" \
-t "$THREADS" \
-b "$BATCH" \
-ub "$UBATCH" \
$NO_WARMUP \
--cache-ram "$CACHE_RAM" \
--host "$HOST" \
--port "$PORT"
EOF

chmod +x ~/run-llama-gpt-oss.sh
```

Run it:

```bash
~/run-llama-gpt-oss.sh
```

## Test command

In another terminal:

```bash
curl -N http://127.0.0.1:8080/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "gpt-oss-20b",
"stream": true,
"messages": [
{
"role": "user",
"content": "Output only valid Python code. No markdown. Create a small Dog class with name, breed, age, tricks, add_trick(), and __str__()."
}
],
"temperature": 0.2,
"max_tokens": 250
}'
```

## About auto-detecting `max_tokens`

`max_tokens` is **per request**, not really a server setting. The server can control context size with `-c`, but each API request should still set `max_tokens`.

Simple rule:

```text
Small answer: max_tokens 50-150
Small code: max_tokens 200-500
Medium code: max_tokens 800-1500
Long file/design: max_tokens 2000+
```

For the P40, I’d keep most tests at:

```json
"max_tokens": 250
```

Then increase only when needed.

## Add a simple curl wrapper

Create this:

```bash
cat > ~/ask-llama.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

PROMPT="${*:-Say hello.}"
MAX_TOKENS="${MAX_TOKENS:-300}"

curl -s http://127.0.0.1:8080/v1/chat/completions \
-H 'Content-Type: application/json' \
-d "$(jq -n \
--arg prompt "$PROMPT" \
--argjson max_tokens "$MAX_TOKENS" \
'{
model: "gpt-oss-20b",
messages: [
{
role: "user",
content: $prompt
}
],
temperature: 0.2,
max_tokens: $max_tokens
}')" | jq -r '.choices[0].message.content'
EOF

chmod +x ~/ask-llama.sh
```

Use it:

```bash
~/ask-llama.sh "Output only valid Python code. Create a hello world script."
```

With more output:

```bash
MAX_TOKENS=800 ~/ask-llama.sh "Output only valid Python code. Create a Dog class with name, breed, age, tricks, add_trick(), and __str__()."
```

## My final recommendation

For your P40, use:

```bash
GGML_CUDA_DISABLE_GRAPHS=1
-c 2048
-np 1
-t 12
-b 512
-ub 256
--cache-ram 0
--no-warmup
```

After it is stable for a while, try performance increases one at a time:

```text
1. Increase -t from 12 to 16
2. Increase -c from 2048 to 4096
3. Increase -b 512 to 1024
4. Re-enable CUDA graphs only if everything else is stable
```

Do not tune everything at once, because then you will not know what caused the next crash.

[1]: https://developer.nvidia.com/blog/optimizing-llama-cpp-ai-inference-with-cuda-graphs/?utm_source=chatgpt.com "Optimizing llama.cpp AI Inference with CUDA Graphs"

Llama 1

2026-05-13T16:32:10Z

Busk: Created page with "`model.gguf` was just a placeholder. You need to download an actual `.gguf` file, such as: ```text gpt-oss-20b-mxfp4.gguf ``` For GPT-OSS 20B, the Hugging Face repo is: ```..."

`model.gguf` was just a placeholder. You need to download an actual `.gguf` file, such as:

```text
gpt-oss-20b-mxfp4.gguf
```

For GPT-OSS 20B, the Hugging Face repo is:

```text
ggml-org/gpt-oss-20b-GGUF
```

The model page shows `gpt-oss-20b-mxfp4.gguf` as the file used by `llama.cpp` / `llama-cpp-python`, and it also supports direct `llama-server -hf ggml-org/gpt-oss-20b-GGUF`. ([Hugging Face][1])

## Easiest: let `llama.cpp` download it

From your `llama.cpp` directory:

```bash
cd ~/llama.cpp

./build/bin/llama-server \
-hf ggml-org/gpt-oss-20b-GGUF \
-ngl 999 \
-c 4096 \
--host 0.0.0.0 \
--port 8080
```

The official quick start for this repo is basically:

```bash
llama-server -hf ggml-org/gpt-oss-20b-GGUF -c 0 --jinja
```

([Hugging Face][2])

For your P40, I would start with:

```bash
-c 4096
```

rather than unlimited/context auto mode.

## Manual download to a real file

Install the Hugging Face CLI:

```bash
sudo apt install -y python3-pip
python3 -m pip install --user -U huggingface_hub
```

Make sure your user-local Python bin path is active:

```bash
export PATH="$HOME/.local/bin:$PATH"
```

Create a model directory:

```bash
mkdir -p ~/models/gpt-oss-20b
```

Download the GGUF file:

```bash
huggingface-cli download ggml-org/gpt-oss-20b-GGUF \
gpt-oss-20b-mxfp4.gguf \
--local-dir ~/models/gpt-oss-20b \
--local-dir-use-symlinks False
```

Then run it:

```bash
cd ~/llama.cpp

./build/bin/llama-server \
-m ~/models/gpt-oss-20b/gpt-oss-20b-mxfp4.gguf \
-ngl 999 \
-c 4096 \
--host 0.0.0.0 \
--port 8080
```

## Test it

```bash
curl http://127.0.0.1:8080/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "gpt-oss-20b",
"messages": [
{
"role": "user",
"content": "Write a minimal Go HTTP health check server."
}
],
"temperature": 0.2
}'
```

## For Qwen later

Same idea, but choose a Qwen GGUF repo instead. For example, Qwen’s docs show running Qwen models through `llama.cpp` using GGUF files. ([Hugging Face][3])

For now, get GPT-OSS 20B working first with:

```bash
-hf ggml-org/gpt-oss-20b-GGUF
```

or with the downloaded file:

```bash
-m ~/models/gpt-oss-20b/gpt-oss-20b-mxfp4.gguf
```

[1]: https://huggingface.co/ggml-org/gpt-oss-20b-GGUF?utm_source=chatgpt.com "ggml-org/gpt-oss-20b-GGUF"
[2]: https://huggingface.co/ggml-org/gpt-oss-20b-GGUF/resolve/main/README.md?download=true&utm_source=chatgpt.com "285 Bytes"
[3]: https://huggingface.co/docs/inference-endpoints/engines/llama_cpp?utm_source=chatgpt.com "llama.cpp"

Tesla P40 llama.cpp

2026-05-13T16:25:46Z

Busk:

```
sudo apt update
sudo apt install -y nvidia-cuda-toolkit
sudo apt install -y git cmake build-essential curl libcurl4-openssl-dev

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j"$(nproc)"
```

That error is simple: **your NVIDIA driver is installed, but the CUDA Toolkit compiler is not.**

`nvidia-smi` working means the **driver/runtime** is working.
Building `llama.cpp` with CUDA requires **`nvcc`**, which comes from the **CUDA Toolkit**, not from `nvidia-utils`. NVIDIA’s CUDA Linux install guide separates the driver from CUDA development tools/toolkit. ([NVIDIA Docs][1])

Check:

```bash
which nvcc
nvcc --version
```

Right now those probably fail.

## Best fix on Ubuntu 24.04

Since you are using `580-server` for the Tesla P40, I would install the Ubuntu CUDA toolkit package first:

```bash
sudo apt update
sudo apt install -y nvidia-cuda-toolkit
```

Then verify:

```bash
which nvcc
nvcc --version
```

Then rebuild `llama.cpp` cleanly:

```bash
cd ~/llama.cpp

rm -rf build

cmake -B build \
-DGGML_CUDA=ON \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_CUDA_ARCHITECTURES=61

cmake --build build --config Release -j"$(nproc)"
```

The important part for Tesla P40 is:

```bash
-DCMAKE_CUDA_ARCHITECTURES=61
```

P40 is Pascal, compute capability **6.1**. Setting that explicitly avoids CMake trying to guess or building unnecessary architectures.

## If `nvidia-cuda-toolkit` is too old or missing

Use NVIDIA’s CUDA repo/toolkit packages instead. For a P40, I would avoid chasing CUDA 13 unless needed. CUDA 12.x is safer for Pascal-era cards and llama.cpp.

Example pattern:

```bash
sudo apt install -y cuda-toolkit-12-8
```

Some Ubuntu 24.04 CUDA install docs show installing `cuda-toolkit-12-8` from NVIDIA’s repo after adding the CUDA repo/keyring. ([docs.leaf.cloud][2])

But try this first:

```bash
sudo apt install -y nvidia-cuda-toolkit
```

## Do not reinstall the NVIDIA driver

Do **not** run a broad CUDA installer that replaces your working `580-server` driver with 590/595.

You want:

```text
Driver: nvidia-driver-580-server
CUDA toolkit: nvcc/compiler only
llama.cpp: built with GGML_CUDA=ON
Arch: 61 for Tesla P40
```

After build, test:

```bash
./build/bin/llama-cli --help | grep -i cuda
./build/bin/llama-bench --help
```

Then run a small model or server with:

```bash
./build/bin/llama-server \
-m /path/to/model.gguf \
-ngl 999 \
-c 4096 \
--host 0.0.0.0 \
--port 8080
```

Your driver is fine now; you just need `nvcc`.

[1]: https://docs.nvidia.com/cuda/cuda-installation-guide-linux/?utm_source=chatgpt.com "CUDA Installation Guide for Linux"
[2]: https://docs.leaf.cloud/en/latest/data-science/installing-gpu-drivers/?utm_source=chatgpt.com "Installing NVIDIA Drivers and CUDA on Ubuntu 24.04"

Yes — for a **Tesla P40**, I would use **`llama.cpp` first** for GPT-OSS, Qwen, DeepSeek, Llama, Gemma, etc.

Your P40 is a great cheap 24 GB VRAM card, but it is **Pascal**, so it lacks Tensor Cores and newer datatype acceleration. That makes `llama.cpp` a better fit than heavier stacks like vLLM/TGI for most local single-GPU use.

## Recommendation for your P40

Use this stack:

```text
Best low-friction stack:
llama.cpp + GGUF models + CUDA build

Optional convenience layer:
Ollama or LM Studio

Avoid as first choice on P40:
vLLM, TensorRT-LLM, exllamav2 for GPT-OSS
```

`llama.cpp` has active support for GPT-OSS and GGUF models, and there are ready GGUF builds for `gpt-oss-20b`. Hugging Face’s GGUF page for `ggml-org/gpt-oss-20b-GGUF` shows direct `llama.cpp`, `llama-cpp-python`, Ollama, LM Studio, and Jan usage paths. ([Hugging Face][1])

For Qwen, the official Qwen docs also document running Qwen3/Qwen3MoE with `llama.cpp` and GGUF, with support starting from specific llama.cpp builds. ([Qwen][2])

## What models fit your P40?

With 24 GB VRAM:

| Model type | Recommendation |
| -------------------------------- | ------------------------------------------- |
| GPT-OSS 20B | Good target |
| GPT-OSS 120B | Not realistic on one P40 |
| Qwen 7B / 14B / 30B-A3B MoE | Good targets depending quant |
| DeepSeek Coder / Qwen Coder GGUF | Good for coding |
| Llama 3.x 8B / 70B quantized | 8B easy, 70B partially/offload or CPU spill |
| Mixtral / MoE GGUF | Can work, speed varies |

For your use — Go, SQL, Python, React, infra code — I would start with:

```text
1. Qwen coder GGUF model
2. GPT-OSS 20B GGUF
3. DeepSeek coder/distill GGUF
```

For the P40 specifically, **GGUF quantized models** are the practical path.

## Build `llama.cpp` with CUDA

On Ubuntu:

```bash
sudo apt update
sudo apt install -y git cmake build-essential curl libcurl4-openssl-dev

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j"$(nproc)"
```

Check CUDA offload works:

```bash
./build/bin/llama-cli --help | grep -i gpu
```

## Run GPT-OSS 20B

Example using llama.cpp’s Hugging Face download support:

```bash
./build/bin/llama-server \
-hf ggml-org/gpt-oss-20b-GGUF \
-ngl 999 \
-c 8192 \
--host 0.0.0.0 \
--port 8080
```

Then test OpenAI-compatible API:

```bash
curl http://127.0.0.1:8080/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "gpt-oss-20b",
"messages": [
{"role": "user", "content": "Write a small Go HTTP server with health check."}
],
"temperature": 0.2
}'
```

If VRAM gets tight, reduce context:

```bash
-c 4096
```

Or reduce GPU layers:

```bash
-ngl 60
```

But on a 24 GB P40, for many 20B-ish quantized GGUFs, this should be okay.

## Run a Qwen coder model

For coding, Qwen is probably where I would spend most of my time. Example:

```bash
./build/bin/llama-server \
-hf unsloth/Qwen3-Coder-Next-GGUF \
-ngl 999 \
-c 8192 \
--host 0.0.0.0 \
--port 8080
```

The Unsloth Qwen GGUF page notes recent llama.cpp fixes for Qwen output/tool-calling behavior, so use a fresh llama.cpp build rather than an old distro package. ([Hugging Face][3])

## Should you use Ollama instead?

Ollama is easier, but `llama.cpp` gives you more direct control.

Use **Ollama** if you want simple:

```bash
ollama run hf.co/ggml-org/gpt-oss-20b-GGUF
```

Use **llama.cpp directly** if you care about:

```text
GPU layer tuning
context size tuning
exact GGUF file selection
server flags
benchmarking
performance debugging
```

Given how you work, I’d use **llama.cpp directly** first.

## Should you use vLLM?

For your **P40**, probably no — not as your first runtime.

vLLM is excellent for newer GPUs and serving many users, but it tends to assume newer CUDA paths and benefits heavily from Tensor Cores / modern attention kernels. On Pascal P40, `llama.cpp` is usually simpler and more forgiving.

I would use vLLM when you have something like:

```text
RTX 3090
RTX 4090
RTX PRO 4500 Blackwell
A10/A40/A100/H100/L40S
```

For the P40:

```text
llama.cpp > Ollama > exllamav2/vLLM experiments
```

## My practical recommendation

Start with:

```text
Runtime: llama.cpp
Driver: 580-server
Model format: GGUF
First model: gpt-oss-20b-GGUF
Coding model: Qwen coder GGUF
Context: 4096 or 8192 first
GPU layers: -ngl 999
```

Then benchmark:

```bash
./build/bin/llama-bench -m /path/to/model.gguf -ngl 999
```

For a single Tesla P40, **don’t chase the newest serving framework**. Use stable `580-server`, fresh `llama.cpp`, and GGUF models. That will give you the fewest headaches and the best compatibility.

[1]: https://huggingface.co/ggml-org/gpt-oss-20b-GGUF?utm_source=chatgpt.com "ggml-org/gpt-oss-20b-GGUF"
[2]: https://qwen.readthedocs.io/en/latest/run_locally/llama.cpp.html?utm_source=chatgpt.com "llama.cpp - Qwen - Read the Docs"
[3]: https://huggingface.co/unsloth/Qwen3-Coder-Next-GGUF?utm_source=chatgpt.com "unsloth/Qwen3-Coder-Next-GGUF"

Tesla P40 llama.cpp

2026-05-13T16:21:34Z

Busk:

Tesla P40 llama.cpp

2026-05-13T16:19:32Z

Busk: Created page with "``` sudo apt update sudo apt install -y git cmake build-essential curl libcurl4-openssl-dev git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build -DGGM..."

```
sudo apt update
sudo apt install -y git cmake build-essential curl libcurl4-openssl-dev

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j"$(nproc)"
```

Yes — for a **Tesla P40**, I would use **`llama.cpp` first** for GPT-OSS, Qwen, DeepSeek, Llama, Gemma, etc.

Your P40 is a great cheap 24 GB VRAM card, but it is **Pascal**, so it lacks Tensor Cores and newer datatype acceleration. That makes `llama.cpp` a better fit than heavier stacks like vLLM/TGI for most local single-GPU use.

## Recommendation for your P40

Use this stack:

```text
Best low-friction stack:
llama.cpp + GGUF models + CUDA build

Optional convenience layer:
Ollama or LM Studio

Avoid as first choice on P40:
vLLM, TensorRT-LLM, exllamav2 for GPT-OSS
```

`llama.cpp` has active support for GPT-OSS and GGUF models, and there are ready GGUF builds for `gpt-oss-20b`. Hugging Face’s GGUF page for `ggml-org/gpt-oss-20b-GGUF` shows direct `llama.cpp`, `llama-cpp-python`, Ollama, LM Studio, and Jan usage paths. ([Hugging Face][1])

For Qwen, the official Qwen docs also document running Qwen3/Qwen3MoE with `llama.cpp` and GGUF, with support starting from specific llama.cpp builds. ([Qwen][2])

## What models fit your P40?

With 24 GB VRAM:

| Model type | Recommendation |
| -------------------------------- | ------------------------------------------- |
| GPT-OSS 20B | Good target |
| GPT-OSS 120B | Not realistic on one P40 |
| Qwen 7B / 14B / 30B-A3B MoE | Good targets depending quant |
| DeepSeek Coder / Qwen Coder GGUF | Good for coding |
| Llama 3.x 8B / 70B quantized | 8B easy, 70B partially/offload or CPU spill |
| Mixtral / MoE GGUF | Can work, speed varies |

For your use — Go, SQL, Python, React, infra code — I would start with:

```text
1. Qwen coder GGUF model
2. GPT-OSS 20B GGUF
3. DeepSeek coder/distill GGUF
```

For the P40 specifically, **GGUF quantized models** are the practical path.

## Build `llama.cpp` with CUDA

On Ubuntu:

```bash
sudo apt update
sudo apt install -y git cmake build-essential curl libcurl4-openssl-dev

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j"$(nproc)"
```

Check CUDA offload works:

```bash
./build/bin/llama-cli --help | grep -i gpu
```

## Run GPT-OSS 20B

Example using llama.cpp’s Hugging Face download support:

```bash
./build/bin/llama-server \
-hf ggml-org/gpt-oss-20b-GGUF \
-ngl 999 \
-c 8192 \
--host 0.0.0.0 \
--port 8080
```

Then test OpenAI-compatible API:

```bash
curl http://127.0.0.1:8080/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "gpt-oss-20b",
"messages": [
{"role": "user", "content": "Write a small Go HTTP server with health check."}
],
"temperature": 0.2
}'
```

If VRAM gets tight, reduce context:

```bash
-c 4096
```

Or reduce GPU layers:

```bash
-ngl 60
```

But on a 24 GB P40, for many 20B-ish quantized GGUFs, this should be okay.

## Run a Qwen coder model

For coding, Qwen is probably where I would spend most of my time. Example:

```bash
./build/bin/llama-server \
-hf unsloth/Qwen3-Coder-Next-GGUF \
-ngl 999 \
-c 8192 \
--host 0.0.0.0 \
--port 8080
```

The Unsloth Qwen GGUF page notes recent llama.cpp fixes for Qwen output/tool-calling behavior, so use a fresh llama.cpp build rather than an old distro package. ([Hugging Face][3])

## Should you use Ollama instead?

Ollama is easier, but `llama.cpp` gives you more direct control.

Use **Ollama** if you want simple:

```bash
ollama run hf.co/ggml-org/gpt-oss-20b-GGUF
```

Use **llama.cpp directly** if you care about:

```text
GPU layer tuning
context size tuning
exact GGUF file selection
server flags
benchmarking
performance debugging
```

Given how you work, I’d use **llama.cpp directly** first.

## Should you use vLLM?

For your **P40**, probably no — not as your first runtime.

vLLM is excellent for newer GPUs and serving many users, but it tends to assume newer CUDA paths and benefits heavily from Tensor Cores / modern attention kernels. On Pascal P40, `llama.cpp` is usually simpler and more forgiving.

I would use vLLM when you have something like:

```text
RTX 3090
RTX 4090
RTX PRO 4500 Blackwell
A10/A40/A100/H100/L40S
```

For the P40:

```text
llama.cpp > Ollama > exllamav2/vLLM experiments
```

## My practical recommendation

Start with:

```text
Runtime: llama.cpp
Driver: 580-server
Model format: GGUF
First model: gpt-oss-20b-GGUF
Coding model: Qwen coder GGUF
Context: 4096 or 8192 first
GPU layers: -ngl 999
```

Then benchmark:

```bash
./build/bin/llama-bench -m /path/to/model.gguf -ngl 999
```

For a single Tesla P40, **don’t chase the newest serving framework**. Use stable `580-server`, fresh `llama.cpp`, and GGUF models. That will give you the fewest headaches and the best compatibility.

[1]: https://huggingface.co/ggml-org/gpt-oss-20b-GGUF?utm_source=chatgpt.com "ggml-org/gpt-oss-20b-GGUF"
[2]: https://qwen.readthedocs.io/en/latest/run_locally/llama.cpp.html?utm_source=chatgpt.com "llama.cpp - Qwen - Read the Docs"
[3]: https://huggingface.co/unsloth/Qwen3-Coder-Next-GGUF?utm_source=chatgpt.com "unsloth/Qwen3-Coder-Next-GGUF"