Initial skills documentation — 25 categories, all SKILL.md + references + scripts

skills/devops/server-provisioning-standard/references/netcup-api-auth.md

@@ -0,0 +1,42 @@
+# Netcup SCP API — Authentication
+
+Netcup's Server Control Panel (SCP) uses Keycloak for authentication. Credentials live in `/root/.hermes/.env` as `NETCUP_CUSTOMER`, `NETCUP_PASSWORD`.
+
+## Token endpoint
+
+```
+POST https://servercontrolpanel.de/realms/scp/protocol/openid-connect/token
+Content-Type: application/x-www-form-urlencoded
+
+grant_type=password
+client_id=scp
+username=<customer-number>
+password=<password>
+```
+
+## Pitfalls
+
+### `customer#` prefix breaks auth
+
+**Wrong:** `username=customer%23389212` → `{"error":"invalid_grant","error_description":"Invalid user credentials"}`
+
+**Right:** `username=389212` — just the customer number, no prefix.
+
+The memory stored the format as `customer# + password` which wasted ~10 minutes on Jul 10, 2026. The actual Keycloak username is just the numeric customer ID.
+
+### Different endpoints
+
+The old SCP endpoint pattern (`/scp-core/api/v1/auth/token`) is deprecated. Use the Keycloak realm endpoint above.
+
+## Server listing
+
+```
+GET https://servercontrolpanel.de/scp-core/api/v1/servers
+Authorization: Bearer <access_token>
+```
+
+Response is a JSON array of server objects with `id`, `name`, `hostname`, `nickname`, `template.name`.
+
+## Fields NOT in the response
+
+The API does NOT return `status`, `mainip`, or `creationdate`. To get IP, query a specific server by ID.

skills/devops/server-provisioning-standard/references/root-ssh-exception.md

@@ -0,0 +1,36 @@
+# Root SSH Exception for Admin Servers
+
+**Standard policy:** `PermitRootLogin no` + `AllowUsers ippadmin` on all servers.
+
+**Exception granted for:** app1, app2, app3 (netcup RS 4000 G12 admin/infrastructure servers).
+
+**Rationale:** Automated provisioning and deployment by Sho'Nuff requires root-level access without sudo password workarounds. These servers run infrastructure services (AI stack, networking management, WordPress platform) that need frequent configuration changes.
+
+**Restrictions:**
+- Root access is **key-only** — no password authentication
+- Only the `itpp-infra` SSH key is authorized
+- `/root/.ssh/authorized_keys` contains the same key as ippadmin's
+- `AllowUsers ippadmin root` — both users explicitly allowed
+- `PasswordAuthentication no` still enforced
+- `PermitRootLogin prohibit-password` (key only, no password)
+
+**Setup commands (from Core):**
+```bash
+ssh -i /root/.ssh/itpp-infra ippadmin@<server>
+# Deploy root's authorized_keys
+sudo mkdir -p /root/.ssh
+sudo cp /home/ippadmin/.ssh/authorized_keys /root/.ssh/
+sudo chmod 700 /root/.ssh
+sudo chmod 600 /root/.ssh/authorized_keys
+# Update sshd_config
+sudo sed -i 's/^PermitRootLogin no/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
+sudo sed -i 's/^AllowUsers.*/AllowUsers ippadmin root/' /etc/ssh/sshd_config
+sudo systemctl restart sshd
+```
+
+**Verification:**
+```bash
+ssh -i /root/.ssh/itpp-infra root@<server> "hostname"
+```
+
+**Pitfall:** If ippadmin was created with `--disabled-password`, `su` and `sudo -S` will fail because there's no password. This blocks automated provisioning via ippadmin. Solution: set up root SSH BEFORE closing the initial root session during provisioning, or use the netcup console.

skills/devops/server-provisioning-standard/references/siteground-dns.md

@@ -0,0 +1,29 @@
+# SiteGround DNS Management
+
+**Key discovery — Jul 10, 2026:** Multiple domains under IT Pro Partner use SiteGround nameservers, NOT Cloudflare. This was discovered when Cloudflare API queries for `app1.itpropartner.com` returned zero results.
+
+## Affected Domains
+
+Domains with `ns1.siteground.net` / `ns2.siteground.net` nameservers:
+
+- `itpropartner.com` — confirmed SiteGround DNS
+- `apextrackexperience.com` — confirmed SiteGround DNS
+- `forefrontwireless.com` — likely SiteGround
+- `germainebrown.com` — likely SiteGround
+- Others — verify per domain
+
+## Detection
+
+```bash
+host -t NS <domain>
+# If nameservers are ns1.siteground.net / ns2.siteground.net → SiteGround
+# If nameservers are *.ns.cloudflare.com → Cloudflare
+```
+
+## Management
+
+DNS changes must be made through the **SiteGround control panel** (siteground.com login), NOT Cloudflare. There is no known API for SiteGround DNS management.
+
+## Migration Plan
+
+Germaine is moving DNS from SiteGround to Cloudflare gradually. Until then, always check `host -t NS` before assuming a domain is managed through Cloudflare.