/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: