Source: https://mayphus.org/systems-freebsd-base/
Title: Reading a FreeBSD system before changing it
Metadata: {"kind":"page","language":"en","route":"/systems-freebsd-base/","tags":["systems","learning","freebsd"],"type":"page"}

Reading a FreeBSD system before changing it

## Goal and environment

Learn to connect a program to its user, files, service configuration and network state. This is the FreeBSD branch of [Understanding computer systems](/understanding-computer-systems/); it complements my [personal FreeBSD notes](/freebsd/) rather than replacing them.

The commands below target **FreeBSD 15.1-RELEASE**, listed on the [official support page](https://www.freebsd.org/security/) when checked on 8 October 2026. They are **proposed exercises, not executed FreeBSD results**: the authoring environment was Linux. Use a disposable FreeBSD VM with an ordinary account. Check the current support table before choosing an installation image. These are FreeBSD instructions, not a recipe for every BSD or a translation of Linux commands.

## Read identity and permissions together

A process acts with credentials; a file has ownership and access rules. Your login name alone does not explain a denied operation. Directory search permission controls traversal, while directory write permission affects creating or removing entries. A file's read/write bits answer a different question. ACLs and file flags can add constraints beyond the familiar mode bits. See the [Handbook's basics chapter](https://docs.freebsd.org/en/books/handbook/basics/).

**Exercise — FreeBSD 15.1, ordinary account:**

```sh
uname -s
freebsd-version -u
id
pwd
ls -ld . /tmp /etc
ls -l /etc/rc.conf
```

Expect an OS name, an installed userland version, user/group IDs, a working directory and ownership/mode information. The release may include a patch suffix. These outputs differ across installations; do not copy somebody else's IDs as a target configuration. A missing `rc.conf` is evidence about this installation, not a reason to create one during the exercise.

Write a sentence explaining which directory your shell occupies and whether your account appears to own it. Keep usernames and paths private when sharing results. Do not change permissions to make the example match.

## Separate the base system from installed applications

FreeBSD develops its kernel and base userland together. Third-party applications commonly live under `/usr/local`; their configuration often lives under `/usr/local/etc`. A command's location is a useful clue, but not a complete provenance proof. The [packages and ports chapter](https://docs.freebsd.org/en/books/handbook/ports/) explains the application distribution mechanisms.

**Exercise — FreeBSD 15.1:** inspect directories without installing anything.

```sh
ls -ld /bin /sbin /usr/bin /usr/local
ls -ld /etc/rc.d /usr/local/etc/rc.d
```

A minimal installation may lack a third-party directory. If the administrator confirms the real package manager is already installed, `pkg info` lists installed packages. Otherwise skip it: the base `pkg` bootstrap command can offer to install the package manager. Do not accept a bootstrap prompt for this inspection exercise. A package inventory says what is installed, not which applications are running or whether they are current.

## Distinguish processes, enabled services and logs

A process is a running instance. A service script describes management actions. Boot configuration expresses intent. Those three can disagree: a service can be enabled but stopped, or running after a manual launch. FreeBSD uses its rc system; Linux `systemctl` instructions do not apply here. Read [configuration, services and logging](https://docs.freebsd.org/en/books/handbook/config/) alongside the [`service(8)` manual](https://man.freebsd.org/cgi/man.cgi?format=html&query=service&sektion=8).

**Exercise — FreeBSD 15.1, standard disposable installation:**

```sh
ps -o pid,ppid,stat,comm
service -l
ls -ld /var/log
ls -l /var/log/messages
```

The process view is limited by the command's default selection and system policy; it is not a complete audit of the host. The service list names files in service directories, including any files that are not valid scripts; it is not a health report. Log ownership and size establish whether a file exists and whether your account may read it. No log contents are needed for this first pass. Do not add `sudo`, restart services, or dump an entire log because output seems incomplete.

On a disposable VM whose logs contain no private activity, optionally inspect the last ten messages with `tail -n 10 /var/log/messages` if already readable. Record timestamps and one event category, not raw identifying details. An old or empty log does not prove nothing happened: rotation, routing and application-specific logs matter.

## Separate network configuration from reachability

**Exercise — FreeBSD 15.1:**

```sh
ifconfig -l
netstat -rn
```

The first command lists interface names; the second displays numeric routing information. These inspect local state and do not probe another machine. Interface names depend on drivers and virtual hardware, so do not assume Linux's naming scheme. See [`ifconfig(8)`](https://man.freebsd.org/cgi/man.cgi?format=html&query=ifconfig&sektion=8) and [`netstat(1)`](https://man.freebsd.org/cgi/man.cgi?format=html&query=netstat&sektion=1).

Find loopback and, if present, a default route. A route indicates a forwarding decision; it does not establish working DNS, Internet access, or a listening application. Keep addresses private. If a command is denied, record the limitation rather than escalating privileges.

## Finish with an evidence map

Make six short notes: release, identity, directory ownership, package visibility, process/service distinction, and route visibility. For each, separate what the command showed from what remains unknown. This produces a useful diagnostic starting point without changing the machine.

Continue with [jail boundaries](/systems-freebsd-jails/) or [hardware and boot](/systems-hardware-boot/). A successful desktop VM exercise would not establish that FreeBSD works on a particular NanoPi board; hardware, firmware and driver evidence belong to that separate investigation.