| name | raspi-live-validation |
| description | Safely validate the production Raspberry Pi 4 Pi-hole + Unbound host. Use when: checking live DNS, systemd, cron, root-owned runtime files, auto-update, root hints, Python API, or post-install health without destructive changes. |
| argument-hint | host/user or focus area, e.g. 10.20.30.3 DNS smoke, root hints, API health |
Raspberry Pi Live Validation
Use this skill for non-destructive validation of the user's real Raspberry Pi 4 DNS host. The default posture is production-safe: observe first, dry-run before live mutation, and ask before any remote access.
Default Host Profile
- Hardware/OS: Raspberry Pi 4, Debian/Raspberry Pi OS aarch64, Linux
raspi4 6.12.75+rpt-rpi-v8 or similar.
- DNS stack: host Pi-hole v6 on port 53 forwarding to host Unbound on port 5335.
- Enabled priorities: auto-update, root hints refresh, boot health check, optional Python Suite API.
- Not default priority: NetAlertX and container Pi-hole unless the user asks.
Safety Rules
- Ask for SSH host/user before remote commands. Do not assume credentials.
- Start with client-side DNS checks and read-only host checks.
- Use
--dry-run or DRY_RUN=1 before any workflow that could mutate state.
- Do not run restore, uninstall, package upgrade, Docker mutation, resolver rewrite, reboot, or service-changing commands on production unless the user explicitly confirms that exact operation.
- Do not print secrets from
/etc/pihole-suite/pihole-suite.env; redact API keys and webhook URLs.
Decision Flow
- If no host/user is provided, give local/client-side commands and ask for SSH details only if remote validation is needed.
- If validating from a client machine, use
dig @<pihole-ip> checks first.
- If validating over SSH, use read-only commands first: service status, config inspection, cron listing, file listing, and API smoke tests.
- If a check requires mutation, convert it to dry-run if supported.
- If destructive validation is required, recommend a disposable Debian/Raspberry Pi OS host or VM.
Client-Side DNS Smoke Test
Replace 10.20.30.3 with the Pi-hole IP:
dig @10.20.30.3 google.com
dig @10.20.30.3 pi-hole.net
dig @10.20.30.3 dnssec.works
dig @10.20.30.3 dnssec-failed.org
Expected:
- Normal domains resolve.
dnssec.works resolves.dnssec-failed.org fails or returns no usable answer.- Admin UI is reachable at
http://10.20.30.3/admin.
Read-Only Host Checks
Over SSH, ask for the username and host first. Then use commands like:
hostnamectl
uname -a
systemctl status pihole-FTL unbound pihole-boot-check.service --no-pager
sudo crontab -l
ls -la /usr/local/lib/pihole-suite /usr/local/lib/pihole-suite/scripts /usr/local/lib/pihole-suite/scripts/lib
ls -la /usr/local/bin/pihole-rescue
sudo grep -A5 '^\[dns\]' /etc/pihole/pihole.toml
sudo unbound-checkconf
dig +short @127.0.0.1 google.com
dig +short @127.0.0.1 -p 5335 google.com
Expected:
- Pi-hole and Unbound services are active or failures are clearly explained.
- Runtime automation points to
/usr/local/lib/pihole-suite, not a git checkout.
- Pi-hole upstream includes
127.0.0.1#5335.
unbound-checkconf passes.
Safe Dry-Run Checks
Use dry-run for workflows that would normally mutate state:
cd ~/pi-hole-unbound-v6
sudo ./install.sh --dry-run --with-auto-update
sudo env DRY_RUN=1 bash /usr/local/lib/pihole-suite/scripts/auto_update.sh
sudo env DRY_RUN=1 bash /usr/local/lib/pihole-suite/scripts/root_hints_refresh.sh
Expected:
- No persistent state, backups, cron/systemd edits, resolver changes, service restarts, notifications, or reboot.
Optional API Smoke Test
If the Python Suite API is enabled, avoid printing the key. Use a redacted flow:
api_key=$(sudo awk -F= '/^SUITE_API_KEY=/{print $2}' /etc/pihole-suite/pihole-suite.env)
curl -sf -H "X-API-Key: $api_key" http://127.0.0.1:8090/health
curl -sf -H "X-API-Key: $api_key" 'http://127.0.0.1:8090/dns?limit=5'
unset api_key
When reporting output, do not include the API key.
Completion Output
End with:
- Host/IP and whether SSH was used.
- Checks run and results.
- Any production-safe issues found.
- Checks intentionally not run because they are destructive or require confirmation.
- Recommended next step, separating production-safe actions from disposable-host tests.
