guardctrl.md

@@ -108,14 +108,13 @@ GUARD_CHANFILE=/opt/rtcds/userapps/release/cds/h1/daqfiles/ini/H1EDCU_GRD.ini
 GUARD_ARCHIVE_ROOT=/ligo/cds/lho/h1/guardian/archive
 NDSSERVER=h1nds0:8088,h1nds1:8088
 ```
-The `GUARD_ARCHIVE_ROOT` variables points a [guardian code archive](guardian-code-archives).
+The `GUARD_ARCHIVE_ROOT` variables points to a [guardian code archive](guardian-code-archives).
 
 ### passwordless SSH interface
 
-The best way to allow remote control of guardctrl is via ssh.
-For a site install on a protected network, where you want to allow "remote" users (i.e. users on the same network but on hosts other than the guardctrl host) to be able to control the nodes without entering a password, you can setup a passwordless ssh "ForceCommand" for the guardctrl user.
+The best way to allow remote control of guardctrl is via ssh.  For a site install on a protected network, where you want to allow "remote" users (i.e. users on the same network but on hosts other than the guardctrl host) to be able to control the nodes without entering a password, you can setup a passwordless ssh "ForceCommand" for the guardctrl user.
 
-First, we need to modify the system PAM stack to allow passwordless login via ssh.  Usually PAM is configured to not allow passwordless login on anything except for special TTYs.  To loosen that restriction, on Debian systems, we modify `/etc/pam.d/common-auth` to change the following line:
+First, modify the system PAM stack to allow passwordless login via ssh.  Usually PAM is configured to not allow passwordless login on anything except for special TTYs.  To loosen that restriction, on Debian systems, we modify `/etc/pam.d/common-auth` to change the following line:
 ```
 auth	[success=1 default=ignore]	pam_unix.so nullok_secure
 ```
@@ -124,8 +123,8 @@ to:
 auth	[success=1 default=ignore]	pam_unix.so nullok
 ```
 
-We then add to the sshd_config a special "Match" stanza for the guardctrl user which specifies that it may login without a password, but is forced to execute only a single command (`guardctrl`).  On most systems this would go in `/etc/ssh/sshd_config`:
-```
+Then add to the `sshd_config` a special "Match" stanza for the guardctrl user which specifies that it may login without a password, but is forced to execute only a single command (`guardctrl`).  On most systems this would go in `/etc/ssh/sshd_config`:
+```/etc/ssh/sshd_config
 Match User guardian
   PermitEmptyPasswords yes
   PermitTTY yes
@@ -141,7 +140,7 @@ If for some reason you need to pass special environment variables to `guardctrl`
 
 #### local guardian user access
 
-Occasionally it might be necessary to access the guardian user directly.  If passwordless SSH access has been enabled as described above, you won't be able to access a guardian user terminal via ssh directly, and you'll need to use e.g. su or sudo from root.  However, su and sudo do not provide access to the user dbus session needed to interact with `systemctl --user`.  The systemd-container package includes the `machinectl` interface whose `shell` command allows for a clean user environment with all dbus interfaces available:
+Occasionally it might be necessary to access the guardian user directly, via e.g a terminal.  If passwordless SSH access has been enabled as described above, then it won't be possible to access a guardian user terminal via ssh directly, and you'll need to change user from root.  However, su and sudo do not provide access to the user dbus session needed to interact with `systemctl --user`.  The `systemd-container` package includes the `machinectl` interface whose `shell` command allows for a clean user environment with all dbus interfaces available:
 ```shell
 root@h1guardian1:~# machinectl shell guardian@ /bin/bash
 guardian@h1guardian1:~$ systemctl --user status