Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

netbox-best-practices

Estrelas3

Forks1

Atualizado17 de junho de 2026 às 06:26

NetBox 4.2-4.6 deployment and upgrade knowledge that the official netboxlabs/skills marketplace does NOT cover - use for deploying or upgrading NetBox on Kubernetes with the netbox-community helm chart (netbox-chart), external PostgreSQL/valkey wiring, API token bootstrap on 4.5+ (nbt_ v2 tokens), plugin installation in the official image, version-migration planning between NetBox 4.2 and 4.6, module type profiles, and front/rear port (patch panel) API changes. Trigger on "netbox helm", "netbox chart", "netbox kubernetes", "netbox upgrade", "netbox plugin install", "netbox api token bootstrap", "netbox 4.x breaking changes", "netbox oidc/sso group mapping" or "netbox sso hardening", or seeding/automation that must survive a NetBox version bump. For general NetBox data modeling, IPAM design, Diode, or validation questions - and for turning on an auth backend in the first place - prefer the official netboxlabs/skills marketplace skills (netbox-administration); this skill only covers the gaps.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

air-gapped

air-gapped/skills

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Administradores de redes e sistemas de computadorInformática e Matemática·SOC 15-1244

Explorador de arquivos

7 arquivos

SKILL.md

readonly

name

netbox-best-practices

description

NetBox Best Practices (helm + version deltas)

This skill COMPLEMENTS the official netboxlabs/skills marketplace (/plugin marketplace add netboxlabs/skills). For data modeling, IPAM design, API patterns, Diode ingestion, or validation, consult those skills first — they are maintained upstream and authoritative. This skill covers three areas they do not (as of 2026-06):

netbox-chart (helm) deployment gotchas → references/helm-chart-gotchas.md
NetBox 4.2→4.6 version-delta cheat sheet → references/version-deltas.md
Modeling gaps: module type profiles (4.3+), port-mapping rework (4.5) → references/modeling-gaps.md
SSO/OIDC group→role mapping + hardening → references/sso-hardening.md

Evidence labels used throughout: [source] = verified against chart/NetBox source code (file:line cited); [live] = verified on a production install of chart 8.3.14 / NetBox v4.6.2; [docs] = official docs/release notes, adversarially verified (3-vote panel).

The five rules that prevent the worst failures

Never commit rendered helm templates. With superuser.password, secretKey, and apiTokenPeppers left empty, every OFFLINE render regenerates them (lookup returns nothing without a live cluster), so helm template output contains fresh random secret material every time. Gitignore template-*.yaml. During a real helm upgrade the chart preserves existing values via lookup. [source: templates/_helpers.tpl]
Name external Postgres clusters differently from the helm release. A Zalando/CNPG cluster named like the release fullname creates a Service with the same name the chart wants to own → helm install fails with "invalid ownership metadata". Convention: <release>-postgres-cluster. [live]
Don't trust the chart's superuser api_token. The chart generates one and mounts it, but NetBox 4.6's entrypoint never seeds it (v2 peppered tokens can't be pre-seeded). Bootstrap real tokens via POST /api/users/tokens/provision/. Details + wire format in references/helm-chart-gotchas.md#api-token-bootstrap. [source+live]
Plugins need a custom image. plugins:/pluginsConfig: values are config-only (rendered into PLUGINS json); the official image ships zero plugin code. Build FROM ghcr.io/netbox-community/netbox:<tag> + RUN /opt/netbox/venv/bin/pip install <plugin>. [source: configmap.yaml]
Check the version-delta sheet before writing API automation. The REST API broke meaningfully at 4.3 (services), 4.5 (tokens, port mappings) — code that worked on 4.2 fails on 4.6 in non-obvious ways. See references/version-deltas.md.

When deploying fresh

Read references/helm-chart-gotchas.md end-to-end first — it is ordered as a pre-flight checklist (external DB, valkey sentinel wiring, secrets layout, first-boot expectations, metrics). First boot runs all Django migrations and takes several minutes before the pod goes Ready; that is normal. [live]

When upgrading NetBox or writing automation against it

Read references/version-deltas.md — it lists what changed in each minor release 4.2→4.6 with dates and PR numbers, plus two "anti-facts" (plausible claims that are FALSE) to avoid repeating common misinformation.

When wiring SSO/OIDC (after the official skill gets it turned on)

Read references/sso-hardening.md. The official netbox-administration skill covers enabling each backend; this file covers the gap it leaves: that the REMOTE_AUTH_SUPERUSER_GROUPS/_STAFF/group-sync settings work ONLY with the header/proxy backend — native OIDC/SAML ignores them and needs a custom SOCIAL_AUTH_PIPELINE function to map IdP groups to NetBox roles — plus the break-glass / header-spoofing / SSO≠API-token hardening rules. [source-verified against netbox 4.6 authentication code]

Mais deste repositório

mesmo repositório

vllm-deployment

air-gapped/skills

Use this skill when authoring, reviewing, or fixing a vLLM Kubernetes manifest, Docker/Podman pod, or OpenShift ServingRuntime — even when the user does not say "vllm". Triggers on: lab cluster performance practices, cache mount + survival across pod restarts (/root/.cache, VLLM_CACHE_ROOT, TORCHINDUCTOR_CACHE_DIR, TRITON_CACHE_DIR, "do we have caches saved"), HF_TOKEN secret in pod env, liveness + readiness probe tuning (initialDelaySeconds, failureThreshold, "pod takes 12 min to boot"), serve_args review, --enforce-eager rationale, MoE deployment ("ep2 dp2", --enable-expert-parallel, expert-parallel sizing), TP/PP sizing, ConfigMap parser-plugin mount, image tag selection, cold-boot reduction, multi-node LWS + Ray, control planes (llm-d, production-stack, AIBrix, NVIDIA Dynamo, KServe), KEDA autoscaling, GAIE routing, disaggregated prefill/decode (Nixl/Mooncake/LMCache/MORI-IO), RHAIIS on OpenShift (SCC, arbitrary UID, Routes 60s, ModelCar, air-gapped). Lead with operator intent, not vendor names.

2026-07-183

skill-improver

air-gapped/skills

Autoresearch loop for Claude Code skills — greedy keep/discard hill climbing on a 10-dimension quality rubric, with blind subagent validation for self-scoring bias, plus a `freshen` mode that probes external references (release notes, docs, deprecation signals) and applies verified updates, plus a `trigger` mode that measures and tunes the skill's frontmatter description until it reliably fires when it should and stays silent when it shouldn't (60/40 train/test split, 3 runs/query, blinded test scores).

2026-07-183

redis-to-valkey

air-gapped/skills

Migrate Redis deployments (especially Bitnami Redis Helm charts in Sentinel HA mode) to Valkey on Kubernetes, including fully air-gapped clusters. Core knowledge: the RDB-version wall (Valkey replicates/loads only from Redis ≤ 7.2.x; Redis 7.4+ writes RDB v12 which Valkey rejects; Valkey 9 writes its own v80 — a one-way door), the two transfer layers (version-bound REPLICAOF/DUMP-RESTORE vs version-agnostic logical replay with RedisShake or rdb-cli), a side-by-side cutover runbook, Valkey chart selection (groundhog2k / CloudPirates / official valkey-io tradeoffs), Bitnami-redis→valkey values translation, consumer-app reconnection (Sentinel discovery, master-set names, frozen redis_version 7.2.4), Prometheus exporter continuity, air-gap tool/image mirroring, and Argo CD source rewiring away from charts.bitnami.com. Part of the bitnami-exit suite.

2026-07-183

airgap-vetting

air-gapped/skills

Vet an open-source product for air-gap readiness BEFORE adoption. Answers eight questions — telemetry, does-opt-out-actually-work, proxy-in-disguise over a hosted API, runtime downloads, custom-CA support, feature-level content egress / offline degradation, day-two sustainment (feed mirroring, staleness), and a 4-grade verdict (air-gap-native / possible-with-mirror / proxy-in-disguise / no-go). Two-pass: static grep of source + container image (bundled fingerprint tables work offline), then an optional dynamic harness (--network=none, egress deny+log, mitmproxy CA injection, faketime). Writes AIRGAP-VETTING.json + .md. Use for any "should we adopt X?" question in a disconnected environment, not just when the user says "air gap".

2026-07-183

triage

air-gapped/skills

Triage a batch of raw security findings. Verify each is real, collapse duplicates, re-rank by impact-on-asset x exploitability, and tag with an owner. Takes a directory or file of scanner output and writes TRIAGE.json + TRIAGE.md sorted by what actually needs engineering attention. Use when asked to "triage findings", "validate scanner output", "prioritize vulns", or "review the backlog". Runs interactively by default; pass --auto to skip the interview.

2026-07-093

patch

air-gapped/skills

Generate candidate fixes for verified security findings. Consumes TRIAGE.json (preferred), VULN-FINDINGS.json, or an execution-harness results directory. Static-analysis input gets a per-finding patch subagent + an independent reviewer and is written as inert diffs for human review; results-directory input from an external execution harness (the defending-code reference pipeline, if installed) is delegated to its verified build→reproduce→regress→re-attack patch ladder. Writes PATCHES/bug_NN/{patch.diff,patch_result.json}, PATCHES.md, and PATCHES.json. Use when asked to "fix the findings", "patch these vulns", "generate fixes", or "close the loop on triage".

2026-07-053

name

netbox-best-practices

description

NetBox Best Practices (helm + version deltas)

netbox-chart (helm) deployment gotchas → references/helm-chart-gotchas.md
NetBox 4.2→4.6 version-delta cheat sheet → references/version-deltas.md
Modeling gaps: module type profiles (4.3+), port-mapping rework (4.5) → references/modeling-gaps.md
SSO/OIDC group→role mapping + hardening → references/sso-hardening.md

The five rules that prevent the worst failures

Never commit rendered helm templates. With superuser.password, secretKey, and apiTokenPeppers left empty, every OFFLINE render regenerates them (lookup returns nothing without a live cluster), so helm template output contains fresh random secret material every time. Gitignore template-*.yaml. During a real helm upgrade the chart preserves existing values via lookup. [source: templates/_helpers.tpl]
Name external Postgres clusters differently from the helm release. A Zalando/CNPG cluster named like the release fullname creates a Service with the same name the chart wants to own → helm install fails with "invalid ownership metadata". Convention: <release>-postgres-cluster. [live]
Don't trust the chart's superuser api_token. The chart generates one and mounts it, but NetBox 4.6's entrypoint never seeds it (v2 peppered tokens can't be pre-seeded). Bootstrap real tokens via POST /api/users/tokens/provision/. Details + wire format in references/helm-chart-gotchas.md#api-token-bootstrap. [source+live]
Plugins need a custom image. plugins:/pluginsConfig: values are config-only (rendered into PLUGINS json); the official image ships zero plugin code. Build FROM ghcr.io/netbox-community/netbox:<tag> + RUN /opt/netbox/venv/bin/pip install <plugin>. [source: configmap.yaml]
Check the version-delta sheet before writing API automation. The REST API broke meaningfully at 4.3 (services), 4.5 (tokens, port mappings) — code that worked on 4.2 fails on 4.6 in non-obvious ways. See references/version-deltas.md.