[Style] consistency pass

1 files changed, 6 insertions, 18 deletions

diff --git a/modules/Working/pages/openrc.adoc b/modules/Working/pages/openrc.adoc
index 9fe464c..3c617f9 100644
--- a/modules/Working/pages/openrc.adoc
+++ b/modules/Working/pages/openrc.adoc
@@ -1,5 +1,5 @@
-= Working with OpenRC
 // MAINT: openrc, whole page
+= Working with OpenRC
 
 OpenRC is the init system used in alpine.
 The init system manages the services, startup and shutdown of your computer.
@@ -13,12 +13,9 @@ If in doubt, use the canonical name, as is shown in this document.
 ====
 
 == Normal Usage
-
 === Manipulating Services
-
+// MAINT: openrc, whole page
 ==== Runtime Service Manipulation
-// MAINT: rc-service
-
 You manipulate services on a running system using the `rc-service` command.
 This allows you to start, stop, and check the status of a given service, amongst other things.
 See the following basic examples:
@@ -47,9 +44,8 @@ Only run the specified command if the service is currently started.
 
 NOTE: Services may define additional commands you can use. See more on this in <<_custom_service_commands>>.
 
-==== On-Boot Service Manipulation
 // MAINT: rc-update
-
+==== On-Boot Service Manipulation
 OpenRC operates under a system called "runlevels".
 More on that in <<_switching_runlevels>> and <<_custom_runlevels>>.
 Enabling a service means putting it in a runlevel, usually one that will get loaded automatically (but not necessarily so!).
@@ -72,16 +68,14 @@ rc-update delete chronyd -a <5>
 <5> Remove the chronyd service from all runlevels.
 
 === Configuring Services
-
 Various services may need additional configuration.
 Most will have dedicated configuration files in `/etc` - you can see documentation on the specific service for more details.
 However, some services need configuration applied to them as part of the launch procedure - such as passing a flag to the binary when first started.
 This can be done in the `/etc/conf.d` directory, under the name of the service in question.
 For example, for a service named "base", the configuration file would be `/etc/conf.d/base`.
 
-=== System Status
 // MAINT: rc-status
-
+=== System Status
 The `rc-status` utility is a fast way to view the current state of your system's services.
 By default, it will list all the services in the current runlevel.
 You can select a different runlevel by specifying it, for instance, `rc-status boot` will list all the services in the boot runlevel.
@@ -110,7 +104,6 @@ For example, adding the `sshd` service to the `default` runlevel is creating a s
 Creating a new runlevel thus involves creating a new directory under `/etc/runlevels`.
 
 ==== Runlevel Stacking
-
 Most of the time, you do not want to shut down all of your `default` services if you're switching to the `office` runlevel.
 Runlevel "inheritance" is acheived through runlevel stacking.
 If you pass the `-s` flag to `rc-update`, you can actually add a runlevel to a runlevel.
@@ -124,17 +117,14 @@ rc-update add myvpn office
 ----
 
 ==== Switching Runlevels
-
 Once you have a custom runlevel you want to switch to, you can do so using the `openrc` command.
 As per the above example, you would use `openrc office` to switch to your new runlevel, and `openrc default` to switch back.
 
-=== System Configuration
 // TODO: expand
-
+=== System Configuration
 System-wide configuration of OpenRC happens in `/etc/rc.conf`.
 
 === Multi-Services
-
 In some cases, you may want the same bit of code to do different things under different circumstances.
 For example, normally, the difference between various instances of `agetty` are just the tty they run on.
 In these cases, you can use symlinks to manage dynamic configuration differences.
@@ -146,16 +136,14 @@ The intended way to use this is by symlinking the "base" service (`agetty`) to t
 This mechanism also allows you to specify custom configuration for that service, for more details, see <<_extended_conf_d_names>>.
 
 === Custom Service Commands
-
 Commands other than `start`, `stop` and `status` may be available.
 A common example is `save`, used by `iptables`.
 Their usage is identical to that of the built-in ones.
 You can look inside the `init.d` script at various `extra*commands` variables which give a listing of the available ones.
 // TODO: what's extra_started_commands etc?
 
-=== Extended `conf.d` Names
 // MAINT: the insanity in sh/opnenrc-init.sh.in
-
+=== Extended `conf.d` Names
 There are 4 total files that may play a role in the configuration of a service.
 Assume that `base` stands for the name of the base server, `ext` is the extension (as per <<_multi_services>>) and `runlevel` is the runlevel it's in.
 Under those conditions, the files involved are: