8.9 KiB
NetBSD Overlay
Scope and discovery
NetBSD has separate base-system, rc.d, firewall, and pkgsrc control planes.
Do not use FreeBSD release tooling, OpenBSD rcctl, or Linux systemd/package commands as NetBSD controls.
Record NetBSD release, architecture, kernel, virtualization, base-update state, and support context.
Discover rc configuration, active services, package source, pkgsrc branch/prefix, network owner, firewall owner, and automation.
Identify whether the target is a host, virtual guest, container-like environment, or restricted administrative domain.
Separate base ownership from pkgsrc ownership before making a lifecycle claim.
Treat unknown firewall or configuration provenance as a blocker for mutation.
Read-only preflight
Inspect /etc/rc.conf, /etc/rc.conf.d, rc.d scripts, local overrides, and package-provided script locations.
Inspect bounded relevant logs, process/listener state, and the affected user, client, or dependent boundary.
Inspect pkgsrc repository branch, binary repository configuration, installed packages, prefix, disk space, and transaction impact.
Inspect base release/update state separately from binary package and source-build state.
Discover whether NPF, PF, IPF, or another owner controls active packet filtering.
Identify owner of interfaces, DNS, routes, and persistent network configuration before connectivity work.
Record snapshot/backup and independent recovery evidence for lifecycle operations.
Command preflight
Run only commands available on the observed NetBSD installation. Substitute <service> with the observed rc.d service name. Firewall binary presence is evidence to investigate ownership, not a selection rule. PF inspection requires authorized privilege on the target; a missing, empty, or permission-denied PF result is unknown, not evidence that PF is inactive.
| Question | Read-only command |
|---|---|
| Base release and kernel | sysctl kern.osrelease; uname -a |
| rc.d service and bounded state | service <service> status; grep '^<service>=' /etc/rc.conf /etc/rc.conf.d/* 2>/dev/null; netstat -an |
| Binary package versus pkgsrc state | pkg_info <package>; command -v pkgin >/dev/null 2>&1 && pkgin list <package>; pkg_admin config-var PKG_PATH |
| rc/network ownership | ls /etc/rc.d; `grep -E '^(ifconfig |
| Firewall owner evidence | command -v npfctl >/dev/null 2>&1 && npfctl show; command -v pfctl >/dev/null 2>&1 && sudo -n pfctl -s info; command -v ipfstat >/dev/null 2>&1 && ipfstat -io |
Services and logs
NetBSD rc.d uses /etc/rc, /etc/rc.conf, /etc/rc.d, and documented local override layers.
Do not edit /etc/defaults to make a site-local override.
service is the normal alias for rc.d script actions, but script actions must be confirmed on the target.
Package-installed rc.d scripts may require activation under /etc/rc.d according to package policy.
Before authorized change, inspect enablement, script configuration, bounded logs, process, and listener.
Afterward, verify rc state, logs, listener, and the actual client or dependent-service boundary.
Do not claim service health based only on a script exit status.
Packages and repositories
pkgsrc supports binary packages and source builds; pkg_add operates on binary packages and pkgin may be installed.
Inspect package origin, repository branch, LOCALBASE, dependencies, installed set, and source/binary policy before upgrade.
Changing binary repository branch or package prefix is not an ordinary package update.
Do not mix package locations, alter LOCALBASE, or override dependency protections without following pkgsrc guidance.
Plan disk capacity, service effects, rebuild needs, and application compatibility before broad maintenance.
Verify installed-package state and the expected binary/service boundary after an authorized transaction.
Release and base lifecycle
NetBSD base-system maintenance is distinct from pkgsrc package maintenance.
Use release-specific NetBSD instructions for base updates and release upgrades.
Do not substitute pkg_add, pkgin, or pkgsrc builds for a base-system lifecycle procedure.
Plan kernel, bootloader, drivers, package ABI, service, and application compatibility before an authorized upgrade.
Require explicit lifecycle authorization, maintenance owner, rollback/recovery plan, and post-boot verification.
After reboot, verify host reachability, booted state, critical services, networking, and application boundary.
Networking and firewall ownership
NPF is NetBSD's native packet filter, but a target may use PF, IPF, or another policy owner. Discover active rules, configuration provenance, interface ownership, route, DNS, and automation boundaries before edits. Do not infer the active firewall merely because a command is installed. For firewall, SSH, DNS, routes, interfaces, or VPN changes, pass the connectivity safety gate. It requires explicit authority, retained access, independent recovery, validated rollback, scoped application, and stop condition. Verify administration access and intended traffic or service behavior after the smallest authorized change.
Storage and persistence
Identify root/data filesystems, mounts, encryption, RAID/LVM where present, snapshots, backup scope, and boot recovery. Confirm package/build, log, and temporary-space requirements before lifecycle maintenance. Do not label a snapshot complete recovery without proving boot/data inclusion and application consistency. Persist configuration in the documented local configuration layer rather than a package example or defaults file. For image-managed systems, establish whether local state survives replacement or deployment. Storage, mount, encryption, partition, and deletion work requires the shared lifecycle or destructive gate.
Failure signatures
Defaults-file edit disappears
Symptom: A setting reverts or does not override expected service behavior.
Cause: /etc/defaults was edited instead of the documented local configuration layer.
Evidence: rc configuration precedence and file provenance show the ineffective edit.
Safe next action: Restore ownership and apply the setting through the supported local override path.
Package daemon absent after reboot
Symptom: A package is installed but its daemon does not start during boot. Cause: The package rc.d script was not activated, copied, or enabled under the applicable policy. Evidence: Script location, rc configuration, run output, process, and listener state show the gap. Safe next action: Follow the documented rc.d activation procedure and verify the service boundary.
Package repository or prefix mismatch
Symptom: A binary package transaction expects a different branch, ABI, or prefix.
Cause: pkgsrc repository or LOCALBASE policy drifted from the installed set.
Evidence: Repository configuration, installed package metadata, and prefix paths show inconsistency.
Safe next action: Stop and reconcile pkgsrc policy; do not mix prefixes to clear the error.
Base update attempted with pkg tools
Symptom: A package command is proposed to address a base-system or release transition. Cause: Base and third-party package lifecycles were conflated. Evidence: File ownership and NetBSD release state identify base provenance. Safe next action: Route the task to release-specific NetBSD lifecycle documentation.
Firewall command targets inactive plane
Symptom: A rule command succeeds but policy or traffic does not change as expected. Cause: NPF, PF, IPF, or automation ownership was assumed incorrectly. Evidence: Active ruleset, loaded service/configuration, and traffic evidence reveal the owner. Safe next action: Stop and select the confirmed owner under the connectivity gate.
Service is running but unavailable
Symptom: An rc.d action reports success while clients cannot use the service. Cause: Configuration, listener, dependency, or network path is failing. Evidence: Bounded logs, process/socket state, and boundary probe disagree with rc status. Safe next action: Diagnose the failed layer read-only before another restart.
Handoff
Report NetBSD release, base versus pkgsrc scope, rc.d configuration, package prefix/branch, and network/firewall owners. Include bounded service, package, logs, listener, storage, and external-boundary evidence. State every recovery limitation, lifecycle uncertainty, and unverified assumption. For a mutation, identify scope, rollback artifact, independent recovery route, validation, and stop condition. Exclude sensitive configuration values, unrestricted logs, and cross-platform command assumptions.