merge: resolve conflicts, keep new IMAP self-ban article

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

05-troubleshooting/gemini-cli-manual-update.md

@@ -0,0 +1,47 @@
+# 🛠️ Gemini CLI: Manual Update Guide
+
+If the automatic update fails or you need to force a specific version of the Gemini CLI, use these steps.
+
+## 🔴 Symptom: Automatic Update Failed
+You may see an error message like:
+`✕ Automatic update failed. Please try updating manually`
+
+## 🟢 Manual Update Procedure
+
+### 1. Verify Current Version
+Check the version currently installed on your system:
+```bash
+gemini --version
+```
+
+### 2. Check Latest Version
+Query the npm registry for the latest available version:
+```bash
+npm show @google/gemini-cli version
+```
+
+### 3. Perform Manual Update
+Use `npm` with `sudo` to update the global package:
+```bash
+sudo npm install -g @google/gemini-cli@latest
+```
+
+### 4. Confirm Update
+Verify that the new version is active:
+```bash
+gemini --version
+```
+
+## 🛠️ Troubleshooting Update Failures
+
+### Permissions Issues
+If you encounter `EACCES` errors without `sudo`, ensure your user has permissions or use `sudo` as shown above.
+
+### Registry Connectivity
+If `npm` cannot reach the registry, check your internet connection or any local firewall/proxy settings.
+
+### Cache Issues
+If the version doesn't update, try clearing the npm cache:
+```bash
+npm cache clean --force
+```

05-troubleshooting/gpu-display/qwen-14b-oom-3080ti.md

@@ -0,0 +1,58 @@
+# Qwen2.5-14B OOM on RTX 3080 Ti (12GB)
+
+## Problem
+
+When attempting to run or fine-tune **Qwen2.5-14B** on an NVIDIA RTX 3080 Ti with 12GB of VRAM, the process fails with an Out of Memory (OOM) error:
+
+```
+torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate X GiB (GPU 0; 12.00 GiB total capacity; Y GiB already allocated; Z GiB free; ...)
+```
+
+The 12GB VRAM limit is hit during the initial model load or immediately upon starting the first training step.
+
+## Root Causes
+
+1. **Model Size:** A 14B parameter model in FP16/BF16 requires ~28GB of VRAM just for the weights.
+2. **Context Length:** High context lengths (e.g., 4096+) significantly increase VRAM usage during training.
+3. **Training Overhead:** Even with QLoRA (4-bit quantization), the overhead of gradients, optimizer states, and activations can exceed 12GB for a 14B model.
+
+---
+
+## Solutions
+
+### 1. Pivot to a 7B Model (Recommended)
+
+For a 12GB GPU, a 7B parameter model (like **Qwen2.5-7B-Instruct**) is the sweet spot. It provides excellent performance while leaving enough VRAM for high context lengths and larger batch sizes.
+
+- **VRAM Usage (7B QLoRA):** ~6-8GB
+- **Pros:** Stable, fast, supports long context.
+- **Cons:** Slightly lower reasoning capability than 14B.
+
+### 2. Aggressive Quantization
+
+If you MUST run 14B, use 4-bit quantization (GGUF or EXL2) for inference only. Training 14B on 12GB is not reliably possible even with extreme offloading.
+
+```bash
+# Example Ollama run (uses 4-bit quantization by default)
+ollama run qwen2.5:14b
+```
+
+### 3. Training Optimizations (if attempting 14B)
+
+If you have no choice but to try 14B training:
+- Set `max_seq_length` to 512 or 1024.
+- Use `Unsloth` (it is highly memory-efficient).
+- Enable `gradient_checkpointing`.
+- Set `per_device_train_batch_size = 1`.
+
+---
+
+## Maintenance
+
+Keep your NVIDIA drivers and CUDA toolkit updated. On Windows (MajorRig), ensure WSL2 has sufficient memory allocation in `.wslconfig`.
+
+---
+
+## Tags
+
+#gpu #cuda #oom #qwen #majortwin #llm #fine-tuning

05-troubleshooting/majwiki-setup-and-pipeline.md

@@ -119,3 +119,20 @@ The webhook runs as a systemd service so it survives reboots:
 systemctl status majwiki-webhook
 systemctl restart majwiki-webhook
 ```
+
+---
+
+*Updated 2026-03-13: Obsidian Git plugin dropped. See canonical workflow below.*
+
+## Canonical Publishing Workflow
+
+The Obsidian Git plugin was evaluated but dropped — too convoluted for a simple push. Manual git from the terminal is the canonical workflow.
+
+```bash
+cd ~/Documents/MajorVault
+git add 20-Projects/MajorTwin/08-Wiki/
+git commit -m "wiki: describe your changes"
+git push
+```
+
+From there: Gitea receives the push → fires webhook → majorlab pulls → MkDocs rebuilds → `notes.majorshouse.com` updates.

05-troubleshooting/networking/fail2ban-self-ban-apache-outage.md

@@ -0,0 +1,186 @@
+# Apache Outage: Fail2ban Self-Ban + Missing iptables Rules
+
+## 🛑 Problem
+
+A web server running Apache2 becomes completely unreachable (`ERR_CONNECTION_TIMED_OUT`) despite Apache running normally. SSH access via Tailscale is unaffected.
+
+---
+
+## 🔍 Diagnosis
+
+### Step 1 — Confirm Apache is running
+
+```bash
+sudo systemctl status apache2
+```
+
+If Apache is `active (running)`, the problem is at the firewall layer, not the application.
+
+---
+
+### Step 2 — Test the public IP directly
+
+```bash
+curl -I --max-time 5 http://<PUBLIC_IP>
+```
+
+A **timeout** means traffic is being dropped by the firewall. A **connection refused** means Apache is down.
+
+---
+
+### Step 3 — Check the iptables INPUT chain
+
+```bash
+sudo iptables -L INPUT -n -v
+```
+
+Look for ACCEPT rules on ports 80 and 443. If they're missing and the chain policy is `DROP`, HTTP/HTTPS traffic is being silently dropped.
+
+**Example of broken state:**
+```
+Chain INPUT (policy DROP)
+  ACCEPT  tcp  --  lo       *    ...   # loopback only
+  ACCEPT  tcp  --  tailscale0 *  ...   tcp dpt:22
+  # no rules for port 80 or 443
+```
+
+---
+
+### Step 4 — Check the nftables ruleset for Fail2ban
+
+```bash
+sudo nft list tables
+```
+
+Look for `table inet f2b-table` — this is Fail2ban's nftables table. It operates at **priority `filter - 1`**, meaning it is evaluated *before* the main iptables INPUT chain.
+
+```bash
+sudo nft list ruleset | grep -A 10 'f2b-table'
+```
+
+Fail2ban rejects banned IPs with rules like:
+```
+tcp dport { 80, 443 } ip saddr @addr-set-wordpress-hard reject with icmp port-unreachable
+```
+
+A banned admin IP will be rejected here regardless of any ACCEPT rules downstream.
+
+---
+
+### Step 5 — Check if your IP is banned
+
+```bash
+for jail in $(sudo fail2ban-client status | grep "Jail list" | sed 's/.*://;s/,/ /g'); do
+  echo "=== $jail ==="; sudo fail2ban-client get $jail banip | tr ',' '\n' | grep <YOUR_IP>
+done
+```
+
+---
+
+## ✅ Solution
+
+### Fix 1 — Add missing iptables ACCEPT rules for HTTP/HTTPS
+
+If ports 80/443 are absent from the INPUT chain:
+
+```bash
+sudo iptables -I INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
+sudo iptables -I INPUT -i eth0 -p tcp --dport 443 -j ACCEPT
+```
+
+Persist the rules:
+
+```bash
+sudo netfilter-persistent save
+```
+
+If `netfilter-persistent` is not installed:
+
+```bash
+sudo apt install -y iptables-persistent
+sudo netfilter-persistent save
+```
+
+---
+
+### Fix 2 — Unban your IP from all Fail2ban jails
+
+```bash
+for jail in $(sudo fail2ban-client status | grep "Jail list" | sed 's/.*://;s/,/ /g'); do
+  sudo fail2ban-client set $jail unbanip <YOUR_IP> 2>/dev/null && echo "Unbanned from $jail"
+done
+```
+
+---
+
+### Fix 3 — Add your IP to Fail2ban's ignore list
+
+Edit `/etc/fail2ban/jail.local`:
+
+```bash
+sudo nano /etc/fail2ban/jail.local
+```
+
+Add or update the `[DEFAULT]` section:
+
+```ini
+[DEFAULT]
+ignoreip = 127.0.0.1/8 ::1 <YOUR_IP>
+```
+
+Restart Fail2ban:
+
+```bash
+sudo systemctl restart fail2ban
+```
+
+---
+
+## 🔁 Why This Happens
+
+| Issue | Root Cause |
+|---|---|
+| Missing port 80/443 rules | iptables INPUT chain left incomplete after a manual firewall rework (e.g., SSH lockdown) |
+| Still blocked after adding iptables rules | Fail2ban uses a separate nftables table at higher priority — iptables ACCEPT rules are never reached for banned IPs |
+| Admin IP gets banned | Automated WordPress/Apache probes trigger Fail2ban jails against the admin's own IP |
+
+---
+
+## ⚠️ Key Architecture Note
+
+On servers running both iptables and Fail2ban, the evaluation order is:
+
+1. **`inet f2b-table`** (nftables, priority `filter - 1`) — Fail2ban ban sets; evaluated first
+2. **`ip filter` INPUT chain** (iptables/nftables, policy DROP) — explicit ACCEPT rules
+3. **UFW chains** — IP-specific rules; evaluated last
+
+A banned IP is stopped at step 1 and never reaches the ACCEPT rules in step 2. Always check Fail2ban *after* confirming iptables looks correct.
+
+---
+
+## 🔎 Quick Diagnostic Commands
+
+```bash
+# Check Apache
+sudo systemctl status apache2
+
+# Test public connectivity
+curl -I --max-time 5 http://<PUBLIC_IP>
+
+# Check iptables INPUT chain
+sudo iptables -L INPUT -n -v
+
+# List nftables tables (look for inet f2b-table)
+sudo nft list tables
+
+# Check Fail2ban jail status
+sudo fail2ban-client status
+
+# Check a specific jail's banned IPs
+sudo fail2ban-client status wordpress-hard
+
+# Unban an IP from all jails
+for jail in $(sudo fail2ban-client status | grep "Jail list" | sed 's/.*://;s/,/ /g'); do
+  sudo fail2ban-client set $jail unbanip <YOUR_IP> 2>/dev/null && echo "Unbanned from $jail"
+done
+```