/etc/rc.conf conversion

# `/etc/rc.conf` conversion

The native mechanism for this system is the service bundle. Services are enabled/disabled with service bundle mechanisms, and service environment variables are set with the likes of `envdir` processing a directory within the service bundle. The external formats import subsystem first creates an amalgamated `rc.conf` file which incorporates the information from all of the several system `rc.conf` files as well as from other sources. Then it translates from that amalgamated form into the native mechanisms for this system.

There are three ways in which settings from it are then imported: service presets, dæmon environment variables, and the generation of nonce service bundles.

## Service preset information

One function of `/etc/rc.conf` and `/etc/rc.conf.local` on BSD systems is to enable and disable services. This is done by setting configuration variables, whose names are the name of the service plus a standard suffix, to "YES" or "NO".

The `system-control preset` command automatically imports these settings when determining whether a service should be enabled or disabled.

It only affects the enabled/disable state. A disabled service that does not automatically start at bootstrap can still be manually started later. The Mewburn `rc` system has no notion of being able to manually start disabled services, in contrast, as the Mewburn `rc` mechanism at bootstrap always attempts to start every service. The enable flag actually behaves as an inverted inhibitor, simply blocking all attempts to start the service, bootstrap or otherwise, rather than as a positive selector to select which services to automatically start.

## Dæmon environment information

Another function of `/etc/rc.conf` and `/etc/rc.conf.local` on BSD systems is to hold dæmon environment variable information. Conventionally, environment variables begin with the name of the service.

If you always manipulate dæmon environment variable information with the BSD `rcctl` command, rather than by editing `/etc/rc.conf` and `/etc/rc.conf.local` directly, then environment variable information will be edited directly within service bundles. The toolset comes with a replacement `rcctl` command that translates `get` and `set` subcommands into the service bundle equivalent, editing files in the service bundle's `env/` subdirectory with `system-control set-service-env` and `system-control print-service-env`.

As the manual page mentions, best practice even with the original OpenBSD tool is to not get into the bad habit of using `rcctl set` name`status` instead of `rcctl enable` name and `rcctl disable` name. The `set`/`get` way of doing things not only doesn't work with the `rcctl` shim but doesn't even work for NetBSD, DragonFly BSD, FreeBSD, or other BSDs, none of which are compatible with OpenBSD's unique `rc.conf` variable naming scheme. In contrast, the `enable`/`disable` way of doing things works both with the original tool and the shim. (Ports of the original OpenBSD tool to other BSDs will also likely ensure that `enable`/`disable` do the right thing for the target platform.)

## Nonce service bundles

`/etc/rc.conf` and `/etc/rc.conf.local` on BSD systems also imply the existence of various service bundles, in particular the existence of service bundles for various networking services attached to specific network interfaces.

From the information in those files (as amalgamated, possibly including other sources of network configuration that have been first translated into the BSD form) the import subsystem generates nonce services such as `ifconfig@lo` which are resposible for running network interface configuration commands and dæmons.

The meanings of the various `network_interfaces`, `dhclient_program`, `ifconfig_name`, `ifconfig_name_ipv6`, and `ifconfig_name_aliases` settings that drive this are roughly as described in the `rc.conf` user manual page in FreeBSD and DragonFly BSD. There are some slight variations. For examples:

- Some of the settings that FreeBSD already deprecates are outright not supported in the conversion process. Do not rely upon `ipv4_addrs_name`, `ipv6_enable`, `ipv6_prefer`, `gif_interfaces` and suchlike to work.

- The `dhclient_program` setting is used to switch amongst various DHCP client softwares, and controls which services are enabled.