From ee468e6139528f68d86d21109bafb07e53e0e207 Mon Sep 17 00:00:00 2001 From: Matt Birkholz Date: Sat, 28 Jun 2025 10:51:18 -0600 Subject: [PATCH] Update README.html. --- README.html | 951 +++++++++++++++++++++++++++------------------------- 1 file changed, 491 insertions(+), 460 deletions(-) diff --git a/README.html b/README.html index 2330fbe..0ea101b 100644 --- a/README.html +++ b/README.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - + A Small Institute @@ -24,8 +24,8 @@ an expendable public face (easily wiped clean) while maintaining a secure and private campus that can function with or without the Internet.

-
-

1. Overview

+
+

1. Overview

This small institute has a public server on the Internet, Front, that @@ -48,7 +48,7 @@ connects to Front making the institute email, cloud, etc. available to members off campus.

-
+
                 =                                                   
               _|||_                                                 
         =-The-Institute-=                                           
@@ -95,8 +95,8 @@ uses OpenPGP encryption to secure message content.
-
-

2. Caveats

+
+

2. Caveats

This small institute prizes its privacy, so there is little or no @@ -144,8 +144,8 @@ month) because of this assumption.

-
-

3. The Services

+
+

3. The Services

The small institute's network is designed to provide a number of @@ -157,8 +157,8 @@ policies. On first reading, those subsections should be skipped; they reference particulars first introduced in the following chapter.

-
-

3.1. The Name Service

+
+

3.1. The Name Service

The institute has a public domain, e.g. small.example.org, and a @@ -172,8 +172,8 @@ names like core.

-
-

3.2. The Email Service

+
+

3.2. The Email Service

Front provides the public SMTP (Simple Mail Transfer Protocol) service @@ -247,8 +247,8 @@ setting for the maximum message size is given in a code block labeled configurations wherever <<postfix-message-size>> appears.

-
-

3.2.1. The Postfix Configurations

+
+

3.2.1. The Postfix Configurations

The institute aims to accommodate encrypted email containing short @@ -263,7 +263,7 @@ handle maxi-messages.

-postfix-message-size
- { p: message_size_limit, v: 104857600 }
+postfix-message-size
- { p: message_size_limit, v: 104857600 }
@@ -278,7 +278,7 @@ re-sending the bounce (or just grabbing the go-bag!).

-postfix-queue-times
- { p: delay_warning_time, v: 1h }
+postfix-queue-times
- { p: delay_warning_time, v: 1h }
 - { p: maximal_queue_lifetime, v: 4h }
 - { p: bounce_queue_lifetime, v: 4h }
 

@@ -292,7 +292,7 @@ disables relaying (other than for the local networks).
 

 
 

-postfix-relaying
- p: smtpd_relay_restrictions
+postfix-relaying
- p: smtpd_relay_restrictions
   v: permit_mynetworks reject_unauth_destination
 

 

@@ -304,7 +304,7 @@ effect.
 

 
 

-postfix-maildir
- { p: home_mailbox, v: Maildir/ }
+postfix-maildir
- { p: home_mailbox, v: Maildir/ }
 

 

 
@@ -315,8 +315,8 @@ in the respective roles below.
-
-

3.2.2. The Dovecot Configurations

+
+

3.2.2. The Dovecot Configurations

The Dovecot settings on both Front and Core disable POP and require @@ -330,7 +330,7 @@ The official documentation for Dovecot once was a Wiki but now is

-dovecot-tls
protocols = imap
+dovecot-tls
protocols = imap
 ssl = required
@@ -342,7 +342,7 @@ configuration keeps them from even listening at the IMAP port

-dovecot-ports
service imap-login {
+dovecot-ports
service imap-login {
   inet_listener imap {
     port = 0
   }
@@ -356,7 +356,7 @@ directories.
 

 
 

-dovecot-maildir
mail_location = maildir:~/Maildir
+dovecot-maildir
mail_location = maildir:~/Maildir
 

 

 
@@ -368,15 +368,15 @@ common settings with host specific settings for ssl_cert and
-
-

3.3. The Web Services

+
+

3.3. The Web Services

Front provides the public HTTP service that serves institute web pages at e.g. https://small.example.org/. The small institute initially runs with a self-signed, "snake oil" server certificate, causing browsers to warn of possible fraud, but this certificate is easily -replaced by one signed by a recognized authority, as discussed in The +replaced by one signed by a recognized authority, as discussed in The Front Role.

@@ -431,15 +431,15 @@ will automatically wipe it within 15 minutes.

-
-

3.4. The Cloud Service

+
+

3.4. The Cloud Service

Core runs Nextcloud to provide a private institute cloud at https://core.small.private/nextcloud/. It is managed manually per The Nextcloud Server Administration Guide. The code and data, including especially database dumps, are stored in /Nextcloud/ which -is included in Core's backup procedure as described in Backups. The +is included in Core's backup procedure as described in Backups. The default Apache2 configuration expects to find the web scripts in /var/www/nextcloud/, so the institute symbolically links this to /Nextcloud/nextcloud/. @@ -453,15 +453,15 @@ private network.

-
-

3.5. Accounts

+
+

3.5. Accounts

A small institute has just a handful of members. For simplicity (and thus security) static configuration files are preferred over complex account management systems, LDAP, Active Directory, and the like. The Ansible scripts configure the same set of user accounts on Core and -Front. The Institute Commands (e.g. ./inst new dick) capture the +Front. The Institute Commands (e.g. ./inst new dick) capture the processes of enrolling, modifying and retiring members of the institute. They update the administrator's membership roll, and run Ansible to create (and disable) accounts on Core, Front, Nextcloud, @@ -476,8 +476,8 @@ accomplished via the campus cloud and the resulting desktop files can all be private (readable and writable only by the owner) by default.

-
-

3.5.1. The Administration Accounts

+
+

3.5.1. The Administration Accounts

The institute avoids the use of the root account (uid 0) because @@ -486,21 +486,21 @@ command is used to consciously (conscientiously!) run specific scripts and programs as root. When installation of a Debian OS leaves the host with no user accounts, just the root account, the next step is to create a system administrator's account named sysadm and to give -it permission to use the sudo command (e.g. as described in The +it permission to use the sudo command (e.g. as described in The Front Machine). When installation prompts for the name of an initial, privileged user account the same name is given (e.g. as -described in The Core Machine). Installation may not prompt and +described in The Core Machine). Installation may not prompt and still create an initial user account with a distribution specific name (e.g. pi). Any name can be used as long as it is provided as the value of ansible_user in hosts. Its password is specified by a vault-encrypted variable in the Secret/become.yml file. (The -hosts and Secret/become.yml files are described in The Ansible +hosts and Secret/become.yml files are described in The Ansible Configuration.)

-
-

3.5.2. The Monkey Accounts

+
+

3.5.2. The Monkey Accounts

The institute's Core uses a special account named monkey to run @@ -511,8 +511,8 @@ account is created on Front as well.

-
-

3.6. Keys

+
+

3.6. Keys

The institute keeps its "master secrets" in an encrypted @@ -597,8 +597,8 @@ the administrator's password keep, to install a new SSH key.

-
-

3.7. Backups

+
+

3.7. Backups

The small institute backs up its data, but not so much so that nothing @@ -634,7 +634,7 @@ files mentioned in the Nextcloud database dump).

-private/backup
#!/bin/bash -e
+private/backup
#!/bin/bash -e
 #
 # DO NOT EDIT.  Maintained (will be replaced) by Ansible.
 #
@@ -736,8 +736,8 @@ finish
-
-

4. The Particulars

+
+

4. The Particulars

This chapter introduces Ansible variables intended to simplify @@ -749,13 +749,13 @@ stored in separate files: public/vars.yml a

The example settings in this document configure VirtualBox VMs as -described in the Testing chapter. For more information about how a +described in the Testing chapter. For more information about how a small institute turns the example Ansible code into a working Ansible -configuration, see chapter The Ansible Configuration. +configuration, see chapter The Ansible Configuration.

-
-

4.1. Generic Particulars

+
+

4.1. Generic Particulars

The small institute's domain name is used quite frequently in the @@ -794,8 +794,8 @@ domain_priv: small.private

-
-

4.2. Subnets

+
+

4.2. Subnets

The small institute uses a private Ethernet, two VPNs, and a "wild", @@ -895,7 +895,7 @@ example result follows the code.

-
+

=> 10.62.17.0/24

@@ -908,7 +908,7 @@ code block below. The small institute treats these addresses as sensitive information so again the code block below "tangles" into private/vars.yml rather than public/vars.yml. Two of the addresses are in 192.168 subnets because they are part of a test -configuration using mostly-default VirtualBoxes (described here). +configuration using mostly-default VirtualBoxes (described here).

@@ -1004,19 +1004,19 @@ front_wg_addr:
-
-

5. The Hardware

+
+

5. The Hardware

The small institute's network was built by its system administrator using Ansible on a trusted notebook. The Ansible configuration and scripts were generated by "tangling" the Ansible code included here. -(The Ansible Configuration describes how to do this.) The following +(The Ansible Configuration describes how to do this.) The following sections describe how Front, Gate and Core were prepared for Ansible.

-
-

5.1. The Front Machine

+
+

5.1. The Front Machine

Front is the small institute's public facing server, a virtual machine @@ -1029,8 +1029,8 @@ possible to quickly re-provision a new Front machine from a frontier Internet café using just the administrator's notebook.

-
-

5.1.1. A Digital Ocean Droplet

+
+

5.1.1. A Digital Ocean Droplet

The following example prepared a new front on a Digital Ocean droplet. @@ -1054,7 +1054,7 @@ root@ubuntu#

The freshly created Digital Ocean droplet came with just one account, root, but the small institute avoids remote access to the "super -user" account (per the policy in The Administration Accounts), so the +user" account (per the policy in The Administration Accounts), so the administrator created a sysadm account with the ability to request escalated privileges via the sudo command.

@@ -1077,7 +1077,7 @@ notebook$ The password was generated by gpw, saved in the administrator's password keep, and later added to Secret/become.yml as shown below. (Producing a working Ansible configuration with Secret/become.yml -file is described in The Ansible Configuration.) +file is described in The Ansible Configuration.) 

@@ -1091,7 +1091,7 @@ notebook_     >>Secret/become.yml
 

 After creating the sysadm account on the droplet, the administrator
 concatenated a personal public ssh key and the key found in
-Secret/ssh_admin/ (created by The CA Command) into an admin_keys
+Secret/ssh_admin/ (created by The CA Command) into an admin_keys
 file, copied it to the droplet, and installed it as the
 authorized_keys for sysadm.
 

@@ -1175,8 +1175,8 @@ address.
-
-

5.2. The Core Machine

+
+

5.2. The Core Machine

Core is the small institute's private file, email, cloud and whatnot @@ -1200,7 +1200,7 @@ The following example prepared a new core on a PC with Debian 11 freshly installed. During installation, the machine was named core, no desktop or server software was installed, no root password was set, and a privileged account named sysadm was created (per the policy in -The Administration Accounts). +The Administration Accounts). 

@@ -1216,7 +1216,7 @@ Is the information correct? [Y/n]
 The password was generated by gpw, saved in the administrator's
 password keep, and later added to Secret/become.yml as shown below.
 (Producing a working Ansible configuration with Secret/become.yml
-file is described in The Ansible Configuration.)
+file is described in The Ansible Configuration.)
 

 
 
@@ -1264,7 +1264,7 @@ _                  nagios-nrpe-plugin
 
 

 Next, the administrator concatenated a personal public ssh key and the
-key found in Secret/ssh_admin/ (created by The CA Command) into an
+key found in Secret/ssh_admin/ (created by The CA Command) into an
 admin_keys file, copied it to Core, and installed it as the
 authorized_keys for sysadm.
 

@@ -1304,7 +1304,7 @@ a new, private IP address and a default route.
 

 In the example command lines below, the address 10.227.248.1 was
 generated by the random subnet address picking procedure described in
-Subnets, and is named core_addr in the Ansible code.  The second
+Subnets, and is named core_addr in the Ansible code.  The second
 address, 10.227.248.2, is the corresponding address for Gate's
 Ethernet interface, and is named gate_addr in the Ansible
 code.
@@ -1320,8 +1320,8 @@ At this point Core was ready for provisioning with Ansible.
-
-

5.3. The Gate Machine

+
+

5.3. The Gate Machine

Gate is the small institute's route to the Internet, and the campus @@ -1342,7 +1342,7 @@ USB-Ethernet adapter, or a wireless adapter connected to a campground Wi-Fi access point, etc. -

+
 =============== | ==================================================
                 |                                           Premises
           (Campus ISP)                                              
@@ -1355,8 +1355,8 @@ campground Wi-Fi access point, etc.
                 +----Ethernet switch
-
-

5.3.1. Alternate Gate Topology

+
+

5.3.1. Alternate Gate Topology

While Gate and Core really need to be separate machines for security @@ -1365,7 +1365,7 @@ This avoids the need for a second Wi-Fi access point and leads to the following topology.

-
+
 =============== | ==================================================
                 |                                           Premises
            (House ISP)                                              
@@ -1389,12 +1389,12 @@ its Ethernet and Wi-Fi clients are allowed to communicate).
-
-

5.3.2. Original Gate Topology

+
+

5.3.2. Original Gate Topology

The Ansible code in this document is somewhat dependent on the -physical network shown in the Overview wherein Gate has three network +physical network shown in the Overview wherein Gate has three network interfaces.

@@ -1403,7 +1403,7 @@ The following example prepared a new gate on a PC with Debian 11 freshly installed. During installation, the machine was named gate, no desktop or server software was installed, no root password was set, and a privileged account named sysadm was created (per the policy in -The Administration Accounts). +The Administration Accounts). 

@@ -1419,7 +1419,7 @@ Is the information correct? [Y/n]
 The password was generated by gpw, saved in the administrator's
 password keep, and later added to Secret/become.yml as shown below.
 (Producing a working Ansible configuration with Secret/become.yml
-file is described in The Ansible Configuration.)
+file is described in The Ansible Configuration.)
 

 
 
@@ -1444,7 +1444,7 @@ _                  openssh-server
 
 

 Next, the administrator concatenated a personal public ssh key and the
-key found in Secret/ssh_admin/ (created by The CA Command) into an
+key found in Secret/ssh_admin/ (created by The CA Command) into an
 admin_keys file, copied it to Gate, and installed it as the
 authorized_keys for sysadm.
 

@@ -1484,7 +1484,7 @@ a new, private IP address.
 

 In the example command lines below, the address 10.227.248.2 was
 generated by the random subnet address picking procedure described in
-Subnets, and is named gate_addr in the Ansible code.
+Subnets, and is named gate_addr in the Ansible code.
 

 
 
@@ -1496,7 +1496,7 @@ Gate was also connected to the USB Ethernet dongles cabled to the
 campus Wi-Fi access point and the campus ISP.  The three network
 adapters are known by their MAC addresses, the values of the variables
 gate_lan_mac, gate_wild_mac, and gate_isp_mac.  (For more
-information, see the Gate role's Configure Netplan task.)
+information, see the Gate role's Configure Netplan task.)
 

 
 

@@ -1506,22 +1506,22 @@ At this point Gate was ready for provisioning with Ansible.
-
-

6. The All Role

+
+

6. The All Role

The all role contains tasks that are executed on all of the institute's servers. At the moment there is just the one.

-
-

6.1. Include Particulars

+
+

6.1. Include Particulars

The all role's task contains a reference to a common institute particular, the institute's domain_name, a variable found in the public/vars.yml file. Thus the first task of the all role is to -include the variables defined in this file (described in The +include the variables defined in this file (described in The Particulars). The code block below is the first to tangle into roles/all/tasks/main.yml.

@@ -1535,8 +1535,8 @@ Particulars). The code block below is the first to tangle into
-
-

6.2. Enable Systemd Resolved

+
+

6.2. Enable Systemd Resolved

The systemd-networkd and systemd-resolved service units are not @@ -1593,14 +1593,14 @@ follows these recommendations (and not the suggestion to enable

-
-

6.3. Trust Institute Certificate Authority

+
+

6.3. Trust Institute Certificate Authority

All servers should recognize the institute's Certificate Authority as trustworthy, so its certificate is added to the set of trusted CAs on each host. More information about how the small institute manages its -X.509 certificates is available in Keys. +X.509 certificates is available in Keys.

@@ -1627,15 +1627,15 @@ X.509 certificates is available in Keys.
-
-

7. The Front Role

+
+

7. The Front Role

The front role installs and configures the services expected on the institute's publicly accessible "front door": email, web, VPN. The virtual machine is prepared with an Ubuntu Server install and remote access to a privileged, administrator's account. (For details, see -The Front Machine.) +The Front Machine.)

@@ -1650,11 +1650,11 @@ perhaps with symbolic links to, for example, /etc/letsencrypt/live/small.example.org/fullchain.pem.

-
-

7.1. Include Particulars

+
+

7.1. Include Particulars

-The first task, as in The All Role, is to include the institute +The first task, as in The All Role, is to include the institute particulars. The front role refers to private variables and the membership roll, so these are included was well.

@@ -1676,8 +1676,8 @@ membership roll, so these are included was well.
-
-

7.2. Configure Hostname

+
+

7.2. Configure Hostname

This task ensures that Front's /etc/hostname and /etc/mailname are @@ -1707,8 +1707,8 @@ delivery.

-
-

7.3. Add Administrator to System Groups

+
+

7.3. Add Administrator to System Groups

The administrator often needs to read (directories of) log files owned @@ -1728,8 +1728,8 @@ these groups speeds up debugging.

-
-

7.4. Configure SSH

+
+

7.4. Configure SSH

The SSH service on Front needs to be known to Monkey. The following @@ -1767,8 +1767,8 @@ those stored in Secret/ssh_front/etc/ssh/

- -
-

7.6. Install Rsync

+
+

7.6. Install Rsync

Monkey uses Rsync to keep the institute's public web site up-to-date. @@ -1824,8 +1824,8 @@ Monkey uses Rsync to keep the institute's public web site up-to-date.

-
-

7.7. Install Unattended Upgrades

+
+

7.7. Install Unattended Upgrades

The institute prefers to install security updates as soon as possible. @@ -1840,13 +1840,13 @@ The institute prefers to install security updates as soon as possible.

-
-

7.8. Configure User Accounts

+
+

7.8. Configure User Accounts

User accounts are created immediately so that Postfix and Dovecot can start delivering email immediately, without returning "no such -recipient" replies. The Account Management chapter describes the +recipient" replies. The Account Management chapter describes the members and usernames variables used below.

@@ -1884,8 +1884,8 @@ recipient" replies. The Account Management chapter de
-
-

7.9. Install Server Certificate

+
+

7.9. Install Server Certificate

The servers on Front use the same certificate (and key) to @@ -1915,8 +1915,8 @@ readable by root.

-
-

7.10. Configure Postfix on Front

+
+

7.10. Configure Postfix on Front

Front uses Postfix to provide the institute's public SMTP service, and @@ -1933,7 +1933,7 @@ The appropriate answers are listed here but will be checked

-As discussed in The Email Service above, Front's Postfix configuration +As discussed in The Email Service above, Front's Postfix configuration includes site-wide support for larger message sizes, shorter queue times, the relaying configuration, and the common path to incoming emails. These and a few Front-specific Postfix configurations @@ -1946,7 +1946,7 @@ via which Core relays messages from the campus.

-postfix-front-networks
- p: mynetworks
+postfix-front-networks
- p: mynetworks
   v: >-
      {{ public_wg_net_cidr }}
      127.0.0.0/8
@@ -1962,7 +1962,7 @@ difficult for internal hosts, who do not have (public) domain names.
 

 
 

-postfix-front-restrictions
- p: smtpd_recipient_restrictions
+postfix-front-restrictions
- p: smtpd_recipient_restrictions
   v: >-
      permit_mynetworks
      reject_unauth_pipelining
@@ -1983,13 +1983,13 @@ messages; incoming messages are delivered locally, without
 

 
 

-postfix-header-checks
- p: smtp_header_checks
+postfix-header-checks
- p: smtp_header_checks
   v: regexp:/etc/postfix/header_checks.cf
 

 

 
 

-postfix-header-checks-content
/^Received:/    IGNORE
+postfix-header-checks-content
/^Received:/    IGNORE
 /^User-Agent:/  IGNORE
 

 

@@ -2001,7 +2001,7 @@ Debian default for inet_interfaces.
 

 
 

-postfix-front
- { p: smtpd_tls_cert_file, v: /etc/server.crt }
+postfix-front
- { p: smtpd_tls_cert_file, v: /etc/server.crt }
 - { p: smtpd_tls_key_file, v: /etc/server.key }
 <<postfix-front-networks>>
 <<postfix-front-restrictions>>
@@ -2070,8 +2070,8 @@ start and enable the service.
-
-

7.11. Configure Public Email Aliases

+
+

7.11. Configure Public Email Aliases

The institute's Front needs to deliver email addressed to a number of @@ -2112,8 +2112,8 @@ created by a more specialized role.

-
-

7.12. Configure Dovecot IMAPd

+
+

7.12. Configure Dovecot IMAPd

Front uses Dovecot's IMAPd to allow user Fetchmail jobs on Core to @@ -2122,7 +2122,7 @@ default with POP and IMAP (without TLS) support disabled. This is a bit "over the top" given that Core accesses Front via VPN, but helps to ensure privacy even when members must, in extremis, access recent email directly from their accounts on Front. For more information -about Front's role in the institute's email services, see The Email +about Front's role in the institute's email services, see The Email Service.

@@ -2178,8 +2178,8 @@ and enables it to start at every reboot.
-
-

7.13. Configure Apache2

+
+

7.13. Configure Apache2

This is the small institute's public web site. It is simple, static, @@ -2215,7 +2215,7 @@ taken from https://www

-apache-ciphers
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
+apache-ciphers
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
 SSLHonorCipherOrder on
 SSLCipherSuite {{ [ 'ECDHE-ECDSA-AES128-GCM-SHA256',
                     'ECDHE-ECDSA-AES256-GCM-SHA384',
@@ -2270,7 +2270,7 @@ used on all of the institute's web sites.
 

 
 

-apache-userdir-front
UserDir /home/www-users
+apache-userdir-front
UserDir /home/www-users
 <Directory /home/www-users/>
         Require all granted
         AllowOverride None
@@ -2285,7 +2285,7 @@ HTTPS URLs.
 

 
 

-apache-redirect-front
<VirtualHost *:80>
+apache-redirect-front
<VirtualHost *:80>
         Redirect permanent / https://{{ domain_name }}/
 </VirtualHost>
 

@@ -2310,7 +2310,7 @@ the inside of a VirtualHost block.  They should apply globally.
 

 
 

-apache-front
ServerName {{ domain_name }}
+apache-front
ServerName {{ domain_name }}
 ServerAdmin webmaster@{{ domain_name }}
 
 DocumentRoot /home/www
@@ -2469,8 +2469,8 @@ the users' ~/Public/HTML/ directories.
 

 

 

-

-
7.14. Configure Public WireGuard™ Subnet

+

+
7.14. Configure Public WireGuard™ Subnet

 

 

 Front uses WireGuard™ to provide a public (Internet accessible) VPN
@@ -2479,14 +2479,14 @@ packets between it and the institute's other private networks.
 

 
 

-The following example private/front-wg0.conf configuration recognizes
+The following example private/front-wg0.conf configuration recognizes
 Core by its public key and routes the institute's private networks to
 it.  It also recognizes Dick's notebook and his (replacement) phone,
 assigning them host numbers 4 and 6 on the VPN.
 

 
 

-private/front-wg0.conf
[Interface]
+private/front-wg0.conf
[Interface]
 Address = 10.177.87.1/24
 ListenPort = 39608
 PostUp = wg set %i private-key /etc/wireguard/private-key
@@ -2498,6 +2498,7 @@ assigning them host numbers 4 and 6 on the VPN.
 PublicKey = lGhC51IBgZtlq4H2bsYFuKvPtV0VAEwUvVIn5fW7D0c=
 AllowedIPs = 10.177.87.2
 AllowedIPs = 192.168.56.0/24
+AllowedIPs = 192.168.57.0/24
 AllowedIPs = 10.84.139.0/24
 
 # dick
@@ -2524,19 +2525,20 @@ WireGuard™ tunnel on Dick's notebook, used abroad
PostUp = resolvectl dns %i 192.168.56.1
 PostUp = resolvectl domain %i small.private
 
-# Front
 [Peer]
+EndPoint = 192.168.15.5:39608
 PublicKey = S+6HaTnOwwhWgUGXjSBcPAvifKw+j8BDTRfq534gNW4=
 AllowedIPs = 10.177.87.1
-AllowedIPs = 10.177.87.0/24
 AllowedIPs = 192.168.56.0/24
+AllowedIPs = 192.168.57.0/24
+AllowedIPs = 10.177.87.0/24
 AllowedIPs = 10.84.139.0/24
 

 

 
 

 The following tasks install WireGuard™, configure it with
-private/front-wg0.conf, and enable the service.
+private/front-wg0.conf, and enable the service.
 

 
 

@@ -2575,8 +2577,8 @@ The following tasks install WireGuard™, configure it with
 

 

 

-

-
7.15. Configure Kamailio

+

+
7.15. Configure Kamailio

 

 

 Front uses Kamailio to provide a SIP service on the public VPN so that
@@ -2598,7 +2600,7 @@ specifies the actual IP, known here as front_wg_addr.
 

 
 

-kamailio
listen=udp:{{ front_wg_addr }}:5060
+kamailio
listen=udp:{{ front_wg_addr }}:5060
 

 

 
@@ -2692,22 +2694,22 @@ Finally, Kamailio can be configured and started.
 

 

 

-

-
8. The Core Role

+

+
8. The Core Role

 

 

 The core role configures many essential campus network services as
 well as the institute's private cloud, so the core machine has
 horsepower (CPUs and RAM) and large disks and is prepared with a
 Debian install and remote access to a privileged, administrator's
-account.  (For details, see The Core Machine.)
+account.  (For details, see The Core Machine.)
 

 

-

-
8.1. Include Particulars

+

+
8.1. Include Particulars

 

 

-The first task, as in The Front Role, is to include the institute
+The first task, as in The Front Role, is to include the institute
 particulars and membership roll.
 

 
@@ -2726,8 +2728,8 @@ particulars and membership roll.
 

 

 

-

-
8.2. Configure Hostname

+

+
8.2. Configure Hostname

 

 

 This task ensures that Core's /etc/hostname and /etc/mailname are
@@ -2760,8 +2762,8 @@ proper email delivery.
 

 

 

-

-
8.3. Configure Systemd Resolved

+

+
8.3. Configure Systemd Resolved

 

 

 Core runs the campus name server, so Resolved is configured to use it
@@ -2805,8 +2807,8 @@ list, and to disable its cache and stub listener.
 

 

 

-

-
8.4. Configure Netplan

+

+
8.4. Configure Netplan

 

 

 Core's network interface is statically configured using Netplan and an
@@ -2863,8 +2865,8 @@ fact was an empty hash at first boot on a simulated campus Ethernet.)
 

 

 

-

-
8.5. Configure DHCP For the Private Ethernet

+

+
8.5. Configure DHCP For the Private Ethernet

 

 

 Core speaks DHCP (Dynamic Host Configuration Protocol) using the
@@ -2963,12 +2965,12 @@ the real private/core-dhcpd.conf (<
 

 

 

-

-
8.6. Configure BIND9

+

+
8.6. Configure BIND9

 

 

 Core uses BIND9 to provide name service for the institute as described
-in The Name Service.  The configuration supports reverse name lookups,
+in The Name Service.  The configuration supports reverse name lookups,
 resolving many private network addresses to private domain names.
 

 
@@ -3033,7 +3035,7 @@ probably be used as forwarders rather than Google.
 

 
 

-bind-options
acl "trusted" {
+bind-options
acl "trusted" {
         {{ private_net_cidr }};
         {{ wild_net_cidr }};
         {{ public_wg_net_cidr }};
@@ -3062,7 +3064,7 @@ probably be used as forwarders rather than Google.
 

 
 

-bind-local
include "/etc/bind/zones.rfc1918";
+bind-local
include "/etc/bind/zones.rfc1918";
 
 zone "{{ domain_priv }}." {
         type master;
@@ -3174,8 +3176,8 @@ probably be used as forwarders rather than Google.
 

 

 

-

-
8.7. Add Administrator to System Groups

+

+
8.7. Add Administrator to System Groups

 

 

 The administrator often needs to read (directories of) log files owned
@@ -3195,15 +3197,15 @@ these groups speeds up debugging.
 

 

 

-

-
8.8. Configure Monkey

+

+
8.8. Configure Monkey

 

 

 The small institute runs cron jobs and web scripts that generate
 reports and perform checks.  The un-privileged jobs are run by a
 system account named monkey.  One of Monkey's more important jobs on
 Core is to run rsync to update the public web site on Front (as
-described in *Configure Apache2).
+described in *Configure Apache2).
 

 
 

@@ -3263,8 +3265,8 @@ described in *Configure Apache2).
 

 

 

-

-
8.9. Install Unattended Upgrades

+

+
8.9. Install Unattended Upgrades

 

 

 The institute prefers to install security updates as soon as possible.
@@ -3279,11 +3281,11 @@ The institute prefers to install security updates as soon as possible.
 

 

 

-

-
8.10. Install Expect

+

+
8.10. Install Expect

 

 

-The expect program is used by The Institute Commands to interact
+The expect program is used by The Institute Commands to interact
 with Nextcloud on the command line.
 

 
@@ -3296,12 +3298,12 @@ with Nextcloud on the command line.
 

 

 

-

-
8.11. Configure User Accounts

+

+
8.11. Configure User Accounts

 

 

 User accounts are created immediately so that backups can begin
-restoring as soon as possible.  The Account Management chapter
+restoring as soon as possible.  The Account Management chapter
 describes the members and usernames variables.
 

 
@@ -3339,8 +3341,8 @@ describes the members and usernames variables.
 

 

 

-

-
8.12. Install Server Certificate

+

+
8.12. Install Server Certificate

 

 

 The servers on Core use the same certificate (and key) to authenticate
@@ -3368,8 +3370,8 @@ themselves to institute clients.  They share the /etc/server.crt and
 

 

 

-

-
8.13. Install NTP

+

+
8.13. Install NTP

 

 

 Core uses NTP to provide a time synchronization service to the campus.
@@ -3385,8 +3387,8 @@ The default daemon's default configuration is fine.
 

 

 

-

-
8.14. Configure Postfix on Core

+

+
8.14. Configure Postfix on Core

 

 

 Core uses Postfix to provide SMTP service to the campus.  The default
@@ -3402,7 +3404,7 @@ The appropriate answers are listed here but will be checked
 
 
 

-As discussed in The Email Service above, Core delivers email addressed
+As discussed in The Email Service above, Core delivers email addressed
 to any internal domain name locally, and uses its smarthost Front to
 relay the rest.  Core is reachable only on institute networks, so
 there is little benefit in enabling TLS, but it does need to handle
@@ -3415,7 +3417,7 @@ Core relays messages from any institute network.
 

 
 

-postfix-core-networks
- p: mynetworks
+postfix-core-networks
- p: mynetworks
   v: >-
      {{ private_net_cidr }}
      {{ public_wg_net_cidr }}
@@ -3431,7 +3433,7 @@ Core uses Front to relay messages to the Internet.
 

 
 

-postfix-core-relayhost
- { p: relayhost, v: "[{{ front_wg_addr }}]" }
+postfix-core-relayhost
- { p: relayhost, v: "[{{ front_wg_addr }}]" }
 

 

 
@@ -3443,7 +3445,7 @@ file.
 

 
 

-postfix-transport
.{{ domain_name }}      local:$myhostname
+postfix-transport
.{{ domain_name }}      local:$myhostname
 .{{ domain_priv }}      local:$myhostname
 

 

@@ -3454,7 +3456,7 @@ The complete list of Core's Postfix settings for
 

 
 

-postfix-core
<<postfix-relaying>>
+postfix-core
<<postfix-relaying>>
 - { p: smtpd_tls_security_level, v: none }
 - { p: smtp_tls_security_level, v: none }
 <<postfix-message-size>>
@@ -3525,8 +3527,8 @@ enable the service.  Whenever /etc/postfix/transport is changed, the
 

 

 

-

-
8.15. Configure Private Email Aliases

+

+
8.15. Configure Private Email Aliases

 

 

 The institute's Core needs to deliver email addressed to institute
@@ -3563,8 +3565,8 @@ installed by more specialized roles.
 

 

 

-

-
8.16. Configure Dovecot IMAPd

+

+
8.16. Configure Dovecot IMAPd

 

 

 Core uses Dovecot's IMAPd to store and serve member emails.  As on
@@ -3574,7 +3576,7 @@ top" given that Core is only accessed from private (encrypted)
 networks, but helps to ensure privacy even when members accidentally
 attempt connections from outside the private networks.  For more
 information about Core's role in the institute's email services, see
-The Email Service.
+The Email Service.
 

 
 

@@ -3582,7 +3584,7 @@ The institute follows the recommendation in the package
 README.Debian (in /usr/share/dovecot-core/) but replaces the
 default "snake oil" certificate with another, signed by the institute.
 (For more information about the institute's X.509 certificates, see
-Keys.)
+Keys.)
 

 
 

@@ -3628,8 +3630,8 @@ and enables it to start at every reboot.
 

 

 

-

-
8.17. Configure Fetchmail

+

+
8.17. Configure Fetchmail

 

 

 Core runs a fetchmail for each member of the institute.  Individual
@@ -3646,7 +3648,7 @@ the username.  The template is only used when the record has a
 

 
 

-fetchmail-config
# Permissions on this file may be no greater than 0600.
+fetchmail-config
# Permissions on this file may be no greater than 0600.
 
 set no bouncemail
 set no spambounce
@@ -3665,7 +3667,7 @@ The Systemd service description.
 

 
 

-fetchmail-service
[Unit]
+fetchmail-service
[Unit]
 Description=Fetchmail --idle task for {{ item }}.
 AssertPathExists=/home/{{ item }}/.fetchmailrc
 After=wg-quick@wg0.service
@@ -3782,12 +3784,12 @@ Otherwise the following task might be appropriate.
 

 

 

-

-
8.18. Configure Apache2 

+

+
8.18. Configure Apache2 

 

 

 This is the small institute's campus web server.  It hosts several web
-sites as described in The Web Services.
+sites as described in The Web Services.
 

 
 
@@ -3858,7 +3860,7 @@ naming a sub-directory in the member's home directory on Core.  The
 

-apache-userdir-core
UserDir Public/HTML
+apache-userdir-core
UserDir Public/HTML
 <Directory /home/*/Public/HTML/>
         Require all granted
         AllowOverride None
@@ -3873,7 +3875,7 @@ redirect, the encryption ciphers and certificates.
 

 
 

-apache-live
<VirtualHost *:80>
+apache-live
<VirtualHost *:80>
         ServerName live
         ServerAlias live.{{ domain_priv }}
         ServerAdmin webmaster@core.{{ domain_priv }}
@@ -3900,7 +3902,7 @@ familiar.
 

 
 

-apache-test
<VirtualHost *:80>
+apache-test
<VirtualHost *:80>
         ServerName test
         ServerAlias test.{{ domain_priv }}
         ServerAdmin webmaster@core.{{ domain_priv }}
@@ -3929,7 +3931,7 @@ trained staffers, monitored by a revision control system, etc.
 

 
 

-apache-campus
<VirtualHost *:80>
+apache-campus
<VirtualHost *:80>
         ServerName www
         ServerAlias www.{{ domain_priv }}
         ServerAdmin webmaster@core.{{ domain_priv }}
@@ -4046,8 +4048,8 @@ The a2ensite command enables them.
 

 

 

-

-
8.19. Configure Website Updates

+

+
8.19. Configure Website Updates

 

 

 Monkey on Core runs /usr/local/sbin/webupdate every 15 minutes via a
@@ -4056,7 +4058,7 @@ Monkey on Core runs /usr/local/sbin/webupdate every 15 minutes via a
 

 
 

-private/webupdate
#!/bin/bash -e
+private/webupdate
#!/bin/bash -e
 #
 # DO NOT EDIT.  This file was tangled from institute.org.
 
@@ -4072,7 +4074,7 @@ rsync -avz --delete --chmod=g-w         \
 The following tasks install the webupdate script from private/,
 and create Monkey's cron job.  An example webupdate script is
-provided here.
+provided here.
 

 
 

@@ -4097,12 +4099,12 @@ provided here.
 

 

 

-

-
8.20. Configure Core WireGuard™ Interface

+

+
8.20. Configure Core WireGuard™ Interface

 

 

 Core connects to Front's WireGuard™ service to provide members abroad
-with a route to the campus networks.  As described in Configure Public
+with a route to the campus networks.  As described in Configure Public
 WireGuard™ Subnet for Front, Core is expected to forward packets from/to the
 private networks.
 

@@ -4168,8 +4170,8 @@ The following tasks install WireGuard™, configure it with
 

 

 

-

-
8.21. Configure NAGIOS

+

+
8.21. Configure NAGIOS

 

 

 Core runs a nagios4 server to monitor "services" on institute hosts.
@@ -4251,8 +4253,8 @@ Core and Campus (and thus Gate) machines.
 

 

-

-
8.21.1. Configure NAGIOS Monitors for Core

+

+
8.21.1. Configure NAGIOS Monitors for Core

 

 

 The first block in nagios.cfg specifies monitors for services on
@@ -4327,8 +4329,8 @@ used here may specify plugin arguments.
 

 

 

-

-
8.21.2. Custom NAGIOS Monitor inst_sensors

+

+
8.21.2. Custom NAGIOS Monitor inst_sensors

 

 

 The check_sensors plugin is included in the package
@@ -4440,8 +4442,8 @@ Core.
 

 

 

-

-
8.21.3. Configure NAGIOS Monitors for Remote Hosts

+

+
8.21.3. Configure NAGIOS Monitors for Remote Hosts

 

 

 The following sections contain code blocks specifying monitors for
@@ -4458,12 +4460,12 @@ plugin with pre-defined arguments appropriate for the institute.  The
 commands are defined in code blocks interleaved with the blocks that
 monitor them.  The command blocks are appended to nrpe.cfg and the
 monitoring blocks to nagios.cfg.  The nrpe.cfg file is installed
-on each campus host by the campus role's Configure NRPE tasks.
+on each campus host by the campus role's Configure NRPE tasks.
 

 

 

-

-
8.21.4. Configure NAGIOS Monitors for Gate

+

+
8.21.4. Configure NAGIOS Monitors for Gate

 

 

 Define the monitored host, gate.  Monitor its response to network
@@ -4594,12 +4596,12 @@ Monitor inst_sensors on Gate.
 

 

 

-

-
8.22. Configure Backups

+

+
8.22. Configure Backups

 

 

 The following task installs the backup script from private/.  An
-example script is provided in here.
+example script is provided in here.
 

 
 

@@ -4614,20 +4616,20 @@ example script is provided in here.
 

 

 

-

-
8.23. Configure Nextcloud

+

+
8.23. Configure Nextcloud

 

 

 Core runs Nextcloud to provide a private institute cloud, as described
-in The Cloud Service.  Installing, restoring (from backup), and
+in The Cloud Service.  Installing, restoring (from backup), and
 upgrading Nextcloud are manual processes documented in The Nextcloud
 Admin Manual, Maintenance.  However Ansible can help prepare Core
 before an install or restore, and perform basic security checks
 afterwards.
 

 

-

-
8.23.1. Prepare Core For Nextcloud

+

+
8.23.1. Prepare Core For Nextcloud

 

 

 The Ansible code contained herein prepares Core to run Nextcloud by
@@ -4821,7 +4823,7 @@ created manually.
 The following task would work (mysql_user supports
 check_implicit_admin) but the nextcloud database was not created
 above.  Thus both database and user are created manually, with SQL
-given in the 8.23.5 subsection below, before occ
+given in the 8.23.5 subsection below, before occ
 maintenance:install can run.
 

 
@@ -4859,8 +4861,8 @@ its document root.
 

 

 

-

-
8.23.2. Configure PHP

+

+
8.23.2. Configure PHP

 

 

 The following tasks set a number of PHP parameters for better
@@ -4903,8 +4905,8 @@ performance, as recommended by Nextcloud.
 

 

 

-

-
8.23.3. Create /Nextcloud/

+

+
8.23.3. Create /Nextcloud/

 

 

 The Ansible tasks up to this point have completed Core's LAMP stack
@@ -4962,8 +4964,8 @@ sudo mount /Nextcloud
 

 

 

-

-
8.23.4. Restore Nextcloud

+

+
8.23.4. Restore Nextcloud

 

 

 Restoring Nextcloud in the newly created /Nextcloud/ presumably
@@ -4996,7 +4998,7 @@ The database is restored with the following commands, which assume the
 last dump was made February 20th 2022 and thus was saved in
 /Nextcloud/20220220.bak.  The database will need to be
 created first as when installing Nextcloud.  The appropriate SQL are
-given in Install Nextcloud below.
+given in Install Nextcloud below.
 

 
 

@@ -5014,8 +5016,8 @@ Overview web page.
 

 

 

-

-
8.23.5. Install Nextcloud

+

+
8.23.5. Install Nextcloud

 

 

 Installing Nextcloud in the newly created /Nextcloud/ starts with
@@ -5085,8 +5087,8 @@ Administration > Overview page.
 

 

 

-

-
8.23.6. Afterwards

+

+
8.23.6. Afterwards

 

 

 Whether Nextcloud was restored or installed, there are a few things
@@ -5268,14 +5270,14 @@ run before the next backup.
 

 

 

-

-
9. The Gate Role

+

+
9. The Gate Role

 

 

 The gate role configures the services expected at the campus gate:
 access to the private Ethernet from the untrusted Ethernet (e.g. a
 campus Wi-Fi AP) via VPN, and access to the Internet via NAT.  The
-gate machine uses three network interfaces (see The Gate Machine)
+gate machine uses three network interfaces (see The Gate Machine)
 configured with persistent names used in its firewall rules.
 

 
@@ -5297,8 +5299,8 @@ applied first, by which Gate gets a campus machine's DNS and Postfix
 configurations, etc.
 

 

-

-
9.1. Include Particulars

+

+
9.1. Include Particulars

 

 

 The following should be familiar boilerplate by now.
@@ -5319,8 +5321,8 @@ The following should be familiar boilerplate by now.
 

 

 

-

-
9.2. Configure Netplan 

+

+
9.2. Configure Netplan 

 

 

 Gate's network interfaces are configured using Netplan and two files.
@@ -5416,8 +5418,8 @@ campus ISP without interference from Ansible.
 

 

 

-

-
9.3. UFW Rules

+

+
9.3. UFW Rules

 

 

 Gate uses the Uncomplicated FireWall (UFW) to install its packet
@@ -5441,7 +5443,7 @@ should not be routing their Internet traffic through their VPN.
 

 
 

-ufw-nat
-A POSTROUTING -s {{ private_net_cidr }} -o isp -j MASQUERADE
+ufw-nat
-A POSTROUTING -s {{ private_net_cidr }} -o isp -j MASQUERADE
 -A POSTROUTING -s {{    wild_net_cidr }} -o isp -j MASQUERADE
 

 

@@ -5450,29 +5452,18 @@ should not be routing their Internet traffic through their VPN.
 Forwarding rules are also needed.  The nat table is a post routing
 rule set, so the default routing policy (DENY) will drop packets
 before NAT can translate them.  The following rules are added to allow
-packets to be forwarded from the campus Ethernet or its wild subnet
-to an ISP on the isp interface, and back (if related to an outgoing
-packet).
+packets to be forwarded from the campus Ethernet or its wild subnet to
+an ISP on the isp interface.  A generic routing rule in UFW accepts
+any related or established packet (according to the kernel's
+connection tracking).
 

 
 

-ufw-forward-nat
-A FORWARD -i lan  -o isp  -j ACCEPT
--A FORWARD -i wild -o isp  -j ACCEPT
--A FORWARD -i isp  -o lan  {{ ACCEPT_RELATED }}
--A FORWARD -i isp  -o wild {{ ACCEPT_RELATED }}
+ufw-forward-nat
-A ufw-user-forward -i lan  -o isp -j ACCEPT
+-A ufw-user-forward -i wild -o isp -j ACCEPT
 

 

 
-

-To keep the above code lines short, the template references an
-ACCEPT_RELATED variable, provided by the task, whose value includes
-the following iptables(8) rule specification parameters.
-

-
-
--m state --state ESTABLISHED,RELATED -j ACCEPT
-

-
 

 If "the standard iptables-restore syntax" as it is described in the
 ufw-framework manual page, allows continuation lines, please let us
@@ -5488,31 +5479,48 @@ public and campus VPNs is also allowed.
 

 
 

-ufw-forward-private
-A FORWARD -i lan  -o wg0  -j ACCEPT
--A FORWARD -i wg0  -o lan  -j ACCEPT
+ufw-forward-private
-A ufw-user-forward -i lan  -o wg0 -j ACCEPT
+-A ufw-user-forward -i wg0  -o lan -j ACCEPT
+-A ufw-user-forward -i wg0  -o wg0 -j ACCEPT
 

 

 
+

+The third rule above may seem curious; it is.  It short circuits
+filters in subsequent chains (e.g. ufw-reject-forward) that, by
+default, log and reject packets, even those from subnet to the same
+subnet (if it is a WireGuard™ subnet?).
+

+
 

 Note that there are no forwarding rules to allow packets to pass from
 the wild device to the lan device, just the wg0 device.
 

 

 

-

-
9.4. Install UFW

+

+
9.4. Configure UFW

 

 

 The following tasks install the Uncomplicated Firewall (UFW), set its
-policy in /etc/default/ufw, and install the above rules in
-/etc/ufw/before.rules.  When Gate is configured by ./abbey config
-gate as in the example bootstrap, enabling the firewall should not be
-a problem.  But when configuring a new gate with ./abbey config
-new-gate, enabling the firewall could break Ansible's current and
-future ssh sessions.  For this reason, Ansible does not enable the
-firewall.  The administrator must login and execute the following
-command after Gate is configured or new gate is "in position"
-(connected to old Gate's wild and isp networks).
+policy in /etc/default/ufw, install the NAT rules in
+/etc/ufw/before.rules, and the Forward rules in
+/etc/ufw/user.rules (where the ufw-user-forward chain
+is… mentioned?).
+

+
+

+When Gate is configured by ./abbey config gate as in the example
+bootstrap, enabling the firewall should not be a problem.  But when
+configuring a new gate with ./abbey config new-gate, enabling the
+firewall could break Ansible's current and future ssh sessions.  For
+this reason, Ansible does not enable the firewall.
+

+
+

+The administrator must login and execute the following command after
+Gate is configured or new gate is "in position" (connected to old
+Gate's wild and isp networks).
 

 
 
@@ -5522,7 +5530,7 @@ sudo ufw enable
 

 roles_t/gate/tasks/main.yml

 - name: Install UFW.
-  become:
+  become: yes
   apt: pkg=ufw
 
 - name: Configure UFW policy.
@@ -5539,29 +5547,35 @@ sudo ufw enable
   - { line: "DEFAULT_FORWARD_POLICY=\"DROP\"",
       regexp: "^DEFAULT_FORWARD_POLICY=" }
 
-- name: Configure UFW rules.
+- name: Configure UFW NAT rules.
   become: yes
-  vars:
-    ACCEPT_RELATED: -m state --state ESTABLISHED,RELATED -j ACCEPT
   blockinfile:
-    path: /etc/ufw/before.rules
     block: |
       *nat
       :POSTROUTING ACCEPT [0:0]
       <<ufw-nat>>
       COMMIT
+    dest: /etc/ufw/before.rules
+    insertafter: EOF
+    prepend_newline: yes
 
+- name: Configure UFW FORWARD rules.
+  become: yes
+  blockinfile:
+    block: |
       *filter
       <<ufw-forward-nat>>
       <<ufw-forward-private>>
       COMMIT
+    dest: /etc/ufw/user.rules
     insertafter: EOF
+    prepend_newline: yes
 

 

 

 

-

-
9.5. Configure DHCP For The Wild Ethernet

+

+
9.5. Configure DHCP For The Wild Ethernet

 

 

 To accommodate commodity Wi-Fi access points, as well as wired IoT
@@ -5687,8 +5701,8 @@ command would not be necessary.
 

 

 

-

-
9.6. Configure Campus WireGuard™ Subnet

+

+
9.6. Configure Campus WireGuard™ Subnet

 

 

 Gate uses WireGuard™ to provide a campus VPN service.  Gate's routes
@@ -5700,13 +5714,13 @@ additional route Gate needs is to the public VPN via Core.  The rest
 

 
 

-The following example private/gate-wg0.conf configuration recognizes
+The following example private/gate-wg0.conf configuration recognizes
 a wired IoT appliance, Dick's notebook and his replacement phone,
 assigning them the host numbers 3, 4 and 6 respectively.
 

 
 

-private/gate-wg0.conf
[Interface]
+private/gate-wg0.conf
[Interface]
 Address = 10.84.139.1/24
 ListenPort = 51820
 PostUp = wg set %i private-key /etc/wireguard/private-key
@@ -5735,15 +5749,19 @@ The configuration used on thing, the IoT appliance, looks like this
 

 WireGuard™ tunnel on an IoT appliance
[Interface]
 Address = 10.84.139.2
-PrivateKey = KIwQT5eGOl9w1qOa5I+2xx5kJH3z4xdpmirS/eGdsXY=
+PrivateKey = <hidden>
+PublicKey = LdsCsgfjKCfd5+VKS+Q/dQhWO8NRNygByDO2VxbXlSQ=
+DNS = 192.168.56.1
+Domain = small.private
 
 # Gate
 [Peer]
+EndPoint = 192.168.57.1:51820
 PublicKey = y3cjFnvQbylmH4lGTujpqc8rusIElmJ4Gu9hh6iR7QI=
 AllowedIPs = 10.84.139.1
-AllowedIPs = 10.84.139.0/24
 AllowedIPs = 192.168.56.0/24
 AllowedIPs = 10.177.87.0/24
+AllowedIPs = 10.84.139.0/24
 

 

 
@@ -5761,17 +5779,18 @@ WireGuard™ tunnel on Dick's notebook, used on campus
 
 # Gate
 [Peer]
+EndPoint = 192.168.57.1:51820
 PublicKey = y3cjFnvQbylmH4lGTujpqc8rusIElmJ4Gu9hh6iR7QI=
 AllowedIPs = 10.84.139.1
-AllowedIPs = 10.84.139.0/24
 AllowedIPs = 192.168.56.0/24
 AllowedIPs = 10.177.87.0/24
+AllowedIPs = 10.84.139.0/24
 

 

 
 

 The following tasks install WireGuard™, configure it with
-private/gate-wg0.conf, and enable the service.
+private/gate-wg0.conf, and enable the service.
 

 
 

@@ -5811,8 +5830,8 @@ The following tasks install WireGuard™, configure it with
 

 

 

-

-
10. The Campus Role

+

+
10. The Campus Role

 

 

 The campus role configures generic campus server machines: network
@@ -5828,8 +5847,8 @@ Wireless campus devices register their public keys using the ./inst
 client command which updates the WireGuard™ configuration on Gate.
 

 

-

-
10.1. Include Particulars

+

+
10.1. Include Particulars

 

 

 The following should be familiar boilerplate by now.
@@ -5845,8 +5864,8 @@ The following should be familiar boilerplate by now.
 

 

 

-

-
10.2. Configure Hostname

+

+
10.2. Configure Hostname

 

 

 Clients should be using the expected host name.
@@ -5873,8 +5892,8 @@ Clients should be using the expected host name.
 

 

 

-

-
10.3. Configure Systemd Timesyncd

+

+
10.3. Configure Systemd Timesyncd

 

 

 The institute uses a common time reference throughout the campus.
@@ -5904,8 +5923,8 @@ and file timestamps.
 

 

 

-

-
10.4. Add Administrator to System Groups

+

+
10.4. Add Administrator to System Groups

 

 

 The administrator often needs to read (directories of) log files owned
@@ -5925,8 +5944,8 @@ these groups speeds up debugging.
 

 

 

-

-
10.5. Install Unattended Upgrades

+

+
10.5. Install Unattended Upgrades

 

 

 The institute prefers to install security updates as soon as possible.
@@ -5941,8 +5960,8 @@ The institute prefers to install security updates as soon as possible.
 

 

 

-

-
10.6. Configure Postfix on Campus

+

+
10.6. Configure Postfix on Campus

 

 

 The Postfix settings used by the campus include message size, queue
@@ -6003,8 +6022,8 @@ tasks below.
 

 

 

-

-
10.7. Set Domain Name

+

+
10.7. Set Domain Name

 

 

 The host's fully qualified (private) domain name (FQDN) is set by an
@@ -6027,13 +6046,13 @@ manpage.)
 

 

 

-

-
10.8. Configure NRPE

+

+
10.8. Configure NRPE

 

 

 Each campus host runs an NRPE (a NAGIOS Remote Plugin Executor)
 server so that the NAGIOS4 server on Core can collect statistics.  The
-NAGIOS service is discussed in the Configure NRPE section of The Core
+NAGIOS service is discussed in the Configure NRPE section of The Core
 Role.
 

 
@@ -6087,8 +6106,8 @@ Role.
 

 

 

-

-
11. The Ansible Configuration

+

+
11. The Ansible Configuration

 

 

 The small institute uses Ansible to maintain the configuration of its
@@ -6097,7 +6116,7 @@ runs playbook site.yml to apply the appro
 role(s) to each host.  Examples of these files are included here, and
 are used to test the roles.  The example configuration applies the
 institutional roles to VirtualBox machines prepared according to
-chapter Testing.
+chapter Testing.
 

 
 

@@ -6110,13 +6129,13 @@ while changes to the institute's particulars are committed to a
 separate revision history.
 

 

-

-
11.1. ansible.cfg

+

+
11.1. ansible.cfg

 

 

 The Ansible configuration file ansible.cfg contains just a handful
 of settings, some included just to create a test jig as described in
-Testing.
+Testing.
 

 
 
    
@@ -6125,7 +6144,7 @@ of settings, some included just to create a test jig as described in
 that Python 3 can be expected on all institute hosts.
 
  • vault_password_file is set to suppress prompts for the vault
 password.  The institute keeps its vault password in Secret/ (as
-described in Keys) and thus sets this parameter to
+described in Keys) and thus sets this parameter to
 Secret/vault-password.
    • 
 
  • inventory is set to avoid specifying it on the command line.
    • 
 
  • roles_path is set to the recently tangled roles files in
@@ -6142,8 +6161,8 @@ described in Keys) and thus sets this parameter to
 

 

 

-

-
11.2. hosts

+

+
11.2. hosts

 

 

 The Ansible inventory file hosts describes all of the institute's
@@ -6155,7 +6174,7 @@ describes three test servers named front, core and 
 
 

-hosts
all:
+hosts
all:
   vars:
     ansible_user: sysadm
     ansible_ssh_extra_args: -i Secret/ssh_admin/id_rsa
@@ -6220,8 +6239,8 @@ the Secret/vault-password file.
 

 

 

-

-
11.3. playbooks/site.yml

+

+
11.3. playbooks/site.yml

 

 

 The example playbooks/site.yml playbook (below) applies the
@@ -6254,8 +6273,8 @@ the example inventory: hosts.
 

 

 

-

-
11.4. Secret/vault-password

+

+
11.4. Secret/vault-password

 

 

 As already mentioned, the small institute keeps its Ansible vault
@@ -6267,17 +6286,17 @@ example password matches the example encryptions above.
 

 
 

-Secret/vault-password
alitysortstagess
+Secret/vault-password
alitysortstagess
 

 

 

 

-

-
11.5. Creating A Working Ansible Configuration

+

+
11.5. Creating A Working Ansible Configuration

 

 

 A working Ansible configuration can be "tangled" from this document to
-produce the test configuration described in the Testing chapter.  The
+produce the test configuration described in the Testing chapter.  The
 tangling is done by Emacs's org-babel-tangle function and has
 already been performed with the resulting tangle included in the
 distribution with this document.
@@ -6320,7 +6339,7 @@ would be copied, with appropriate changes, into new subdirectories
 public/ and private/.
 
  • ~/net/Secret would be a symbolic link to the (auto-mounted?)
 location of the administrator's encrypted USB drive, as described in
-section Keys.
    • 
+section Keys.
 
 
 
    
@@ -6356,8 +6375,8 @@ super-project's directory.
 
    
 
    
 
    
-
    
-
    11.6. Maintaining A Working Ansible Configuration
    
+
    
+
    11.6. Maintaining A Working Ansible Configuration
    
 
    
 
    
 The Ansible roles currently tangle into the roles_t/ directory to
@@ -6376,8 +6395,8 @@ their way back to the code block in this document.
 
    
 
    
 
    
-
    
-
    12. The Institute Commands
    
+
    
+
    12. The Institute Commands
    
 
    
 
    
 The institute's administrator uses a convenience script to reliably
@@ -6387,8 +6406,8 @@ Ansible configuration.  The Ansible commands it executes are expected
 to get their defaults from ./ansible.cfg.
 
    
 
    
-
    
-
    12.1. Sub-command Blocks
    
+
    
+
    12.1. Sub-command Blocks
    
 
    
 
    
 The code blocks in this chapter tangle into the inst script.  Each
@@ -6412,8 +6431,8 @@ The first code block is the header of the ./inst script.
 
    
 
    
 
    
-
    
-
    12.2. Sanity Check
    
+
    
+
    12.2. Sanity Check
    
 
    
 
    
 The next code block does not implement a sub-command; it implements
@@ -6473,8 +6492,8 @@ permissions.  It probes past the Secret/ mount poin
 
    
 
    
 
    
-
    
-
    12.3. Importing Ansible Variables
    
+
    
+
    12.3. Importing Ansible Variables
    
 
    
 
    
 To ensure that Ansible and ./inst are sympatico vis-a-vi certain
@@ -6496,9 +6515,10 @@ them.
 
 mysystem "ansible-playbook playbooks/check-inst-vars.yml >/dev/null";
 
-our ($domain_name, $domain_priv, $private_net_cidr,
+our ($domain_name, $domain_priv,
      $front_addr, $front_wg_pubkey,
      $public_wg_net_cidr, $public_wg_port,
+     $private_net_cidr, $wild_net_cidr,
      $gate_wild_addr, $gate_wg_pubkey,
      $campus_wg_net_cidr, $campus_wg_port,
      $core_addr, $core_wg_pubkey);
@@ -6520,15 +6540,16 @@ The playbook that updates private/vars.pl:
       content: |
         $domain_name = "{{ domain_name }}";
         $domain_priv = "{{ domain_priv }}";
-        $private_net_cidr = "{{ private_net_cidr }}";
 
         $front_addr = "{{ front_addr }}";
         $front_wg_pubkey = "{{ front_wg_pubkey }}";
 
         $public_wg_net_cidr = "{{ public_wg_net_cidr }}";
-
         $public_wg_port = "{{ public_wg_port }}";
 
+        $private_net_cidr = "{{ private_net_cidr }}";
+        $wild_net_cidr = "{{ wild_net_cidr }}";
+
         $gate_wild_addr = "{{ gate_wild_addr }}";
         $gate_wg_pubkey = "{{ gate_wg_pubkey }}";
 
@@ -6619,8 +6640,8 @@ the test client to give it different personae.
 
    
 
 
 
    
 
    
 
    
-
    
-
    12.4. The CA Command
    
+
    
+
    12.4. The CA Command
    
 
    
 
    
 The next code block implements the CA sub-command, which creates a
@@ -6720,8 +6741,8 @@ config.
 
    
 
    
 
    
-
    
-
    12.5. The Config Command
    
+
    
+
    12.5. The Config Command
    
 
    
 
    
 The next code block implements the config sub-command, which
@@ -6771,12 +6792,12 @@ Example command lines:
 
    
 
    
 
    
-
    
-
    12.6. Account Management
    
+
    
+
    12.6. Account Management
    
 
    
 
    
 For general information about members and their Unix accounts, see
-Accounts.  The account management sub-commands maintain a mapping
+Accounts.  The account management sub-commands maintain a mapping
 associating member "usernames" (Unix account names) with their
 records.  The mapping is stored among other things in
 private/members.yml as the value associated with the key members.
@@ -6976,8 +6997,8 @@ each record.
 
    
 
    
 
    
-
    
-
    12.7. The New Command
    
+
    
+
    12.7. The New Command
    
 
    
 
    
 The next code block implements the new sub-command.  It adds a new
@@ -7078,8 +7099,8 @@ initial, generated password.
 
    
 
    
 
    
-
    
-
    12.8. The Pass Command
    
+
    
+
    12.8. The Pass Command
    
 
    
 
    
 The institute's passwd command on Core securely emails root with a
@@ -7093,8 +7114,8 @@ Ansible site.yml playbook to update the
 message is sent to member@core.
 
    
 
    
-
    
-
    12.8.1. Less Aggressive passwd.
    
+
    
+
    12.8.1. Less Aggressive passwd.
    
 
    
 
    
 The next code block implements the less aggressive passwd command.
@@ -7190,8 +7211,8 @@ print "
 
    
 
    
 
    
-
    
-
    12.8.2. Less Aggressive Pass Command
    
+
    
+
    12.8.2. Less Aggressive Pass Command
    
 
    
 
    
 The following code block implements the ./inst pass command, used by
@@ -7288,8 +7309,8 @@ users:resetpassword command using expect(1).
 
    
 
    
 
    
-
    
-
    12.8.3. Installing the Less Aggressive passwd
    
+
    
+
    12.8.3. Installing the Less Aggressive passwd
    
 
    
 
    
 The following Ansible tasks install the less aggressive passwd
@@ -7357,8 +7378,8 @@ configuration so that the email to root can be encrypted.
 
    
 
    
 
    
-
    
-
    12.9. The Old Command
    
+
    
+
    12.9. The Old Command
    
 
    
 
    
 The old command disables a member's account (and thus their clients).
@@ -7401,8 +7422,8 @@ The old command disables a member's account (and thus their clients
 
    
 
    
 
    
-
    
-
    12.10. The Client Command
    
+
    
+
    12.10. The Client Command
    
 
    
 
    
 The client command registers the public key of a client wishing to
@@ -7536,6 +7557,7 @@ better support in NetworkManager soon.)
 PublicKey = $core_wg_pubkey
 AllowedIPs = $core_wg_addr
 AllowedIPs = $private_net_cidr
+AllowedIPs = $wild_net_cidr
 AllowedIPs = $campus_wg_net_cidr\n";
 
   write_wg_server ("private/front-wg0.conf", \@member_peers,
@@ -7589,23 +7611,32 @@ better support in NetworkManager soon.)
 
 sub write_wg_client ($$$$$$) {
   my ($file, $addr, $type, $pubkey, $endpt, $server_addr) = @_;
+
   my $O = new IO::File;
+  open ($O, ">$file.tmp") or die "Could not open $file.tmp: $!\n";
+
   my $DNS = ($type eq "android"
              ? "
-DNS=$core_addr\nDomain=$domain_priv"
+DNS = $core_addr
+Domain = $domain_priv"
              : "
+PostUp = wg set %i private-key /etc/wireguard/private-key
 PostUp = resolvectl dns %i $core_addr
 PostUp = resolvectl domain %i $domain_priv");
-  open ($O, ">$file.tmp") or die "Could not open $file.tmp: $!\n";
+
+  my $WILD = ($file eq "public.conf"
+              ? "
+AllowedIPs = $wild_net_cidr"
+              : "");
+
   print $O "[Interface]
-Address = $addr
-PostUp = wg set %i private-key /etc/wireguard/private-key$DNS
+Address = $addr$DNS
 
 [Peer]
 PublicKey = $pubkey
 EndPoint = $endpt
 AllowedIPs = $server_addr
-AllowedIPs = $private_net_cidr
+AllowedIPs = $private_net_cidr$WILD
 AllowedIPs = $public_wg_net_cidr
 AllowedIPs = $campus_wg_net_cidr\n";
   close $O or die "Could not close $file.tmp: $!\n";
@@ -7640,8 +7671,8 @@ better support in NetworkManager soon.)
 
    
 
    
 
    
-
    
-
    12.11. Institute Command Help
    
+
    
+
    12.11. Institute Command Help
    
 
    
 
    
 This should be the last block tangled into the inst script.  It
@@ -7657,8 +7688,8 @@ above.
 
    
 
    
 
    
-
    
-
    13. Testing
    
+
    
+
    13. Testing
    
 
    
 
    
 The example files in this document, ansible.cfg and hosts as well
@@ -7677,7 +7708,7 @@ simulation is the VirtualBox host.
 
    
 The next two sections list the steps taken to create the simulated
 Core, Gate and Front machines, and connect them to their networks.
-The process is similar to that described in The (Actual) Hardware, but
+The process is similar to that described in The (Actual) Hardware, but
 is covered in detail here where the VirtualBox hypervisor can be
 assumed and exact command lines can be given (and copied during
 re-testing).  The remaining sections describe the manual testing
@@ -7693,8 +7724,8 @@ HTML version of the latest revision can be found on the official web
 site at https://www.virtualbox.org/manual/UserManual.html.
 
    
 
    
-
    
-
    13.1. The Test Networks
    
+
    
+
    13.1. The Test Networks
    
 
    
 
    
 The networks used in the test:
@@ -7758,15 +7789,15 @@ on the private 192.168.15.0/24 network.
 
    
 
    
 
    
-
    
-
    13.2. The Test Machines
    
+
    
+
    13.2. The Test Machines
    
 
    
 
    
 The virtual machines are created by VBoxManage command lines in the
 following sub-sections.  They each start with a recent Debian release
 (e.g. debian-12.5.0-amd64-netinst.iso) in their simulated DVD
-drives.  As in The Hardware preparation process being simulated, a few
-additional software packages are installed.  Unlike in The Hardware
+drives.  As in The Hardware preparation process being simulated, a few
+additional software packages are installed.  Unlike in The Hardware
 preparation, machines are moved to their final networks and then
 remote access is authorized.  (They are not accessible via ssh on
 the VirtualBox NAT network where they first boot.)
@@ -7778,8 +7809,8 @@ privileged accounts on the virtual machines, they are prepared for
 configuration by Ansible.
 
    
 
    
-
    
-
    13.2.1. A Test Machine
    
+
    
+
    13.2.1. A Test Machine
    
 
    
 
    
 The following shell function contains most of the VBoxManage
@@ -7910,8 +7941,8 @@ preparation (below).
 
    
 
    
 
    
-
    
-
    13.2.2. The Test Front Machine
    
+
    
+
    13.2.2. The Test Front Machine
    
 
    
 
    
 The front machine is created with 512MiB of RAM, 4GiB of disk, and
@@ -7924,7 +7955,7 @@ After Debian is installed (as detailed above) front is shut down an
 its primary network interface moved to the simulated Internet, the NAT
 network premises.  front also gets a second network interface, on
 the host-only network vboxnet1, to make it directly accessible to
-the administrator's notebook (as described in The Test Networks).
+the administrator's notebook (as described in The Test Networks).
 
    
 
 
    
@@ -7956,13 +7987,13 @@ Note that there is no pre-provisioning for front, which is never
 deployed on a frontier, always in the cloud.  Additional Debian
 packages are assumed to be readily available.  Thus Ansible installs
 them as necessary, but first the administrator authorizes remote
-access by following the instructions in the final section: Ansible
+access by following the instructions in the final section: Ansible
 Test Authorization.
 
    
 
    
 
    
-
    
-
    13.2.3. The Test Gate Machine
    
+
    
+
    13.2.3. The Test Gate Machine
    
 
    
 
    
 The gate machine is created with the same amount of RAM and disk as
@@ -7977,7 +8008,7 @@ create_vm
 
    
 
 
    
-After Debian is installed (as detailed in A Test Machine) and the
+After Debian is installed (as detailed in A Test Machine) and the
 machine rebooted, the administrator logs in and installs several
 additional software packages.
 
    
@@ -8078,12 +8109,12 @@ Ethernet interface is temporarily configured with an IP address.
 
 
    
 Finally, the administrator authorizes remote access by following the
-instructions in the final section: Ansible Test Authorization.
+instructions in the final section: Ansible Test Authorization.
 
    
 
    
 
    
-
    
-
    13.2.4. The Test Core Machine
    
+
    
+
    13.2.4. The Test Core Machine
    
 
    
 
    
 The core machine is created with 1GiB of RAM and 6GiB of disk.
@@ -8100,7 +8131,7 @@ create_vm
 
    
 
 
    
-After Debian is installed (as detailed in A Test Machine) and the
+After Debian is installed (as detailed in A Test Machine) and the
 machine rebooted, the administrator logs in and installs several
 additional software packages.
 
    
@@ -8166,12 +8197,12 @@ Netplan soon.)
 
 
    
 Finally, the administrator authorizes remote access by following the
-instructions in the next section: Ansible Test Authorization.
+instructions in the next section: Ansible Test Authorization.
 
    
 
    
 
    
-
    
-
    13.2.5. Ansible Test Authorization
    
+
    
+
    13.2.5. Ansible Test Authorization
    
 
    
 
    
 To authorize Ansible's access to the three test machines, they must
@@ -8237,8 +8268,8 @@ ssh-keygen -f ~/.ssh/known_hosts -R 192.168.57.3
 
    
 
    
 
    
-
    
-
    13.3. Configure Test Machines
    
+
    
+
    13.3. Configure Test Machines
    
 
    
 
    
 At this point the three test machines core, gate, and front are
@@ -8256,8 +8287,8 @@ not.
 
    
 
    
 
    
-
    
-
    13.4. Test Basics
    
+
    
+
    13.4. Test Basics
    
 
    
 
    
 At this point the test institute is just core, gate and front,
@@ -8319,12 +8350,12 @@ instant attention).
 
    
 
    
 
    
-
    
-
    13.5. The Test Nextcloud
    
+
    
+
    13.5. The Test Nextcloud
    
 
    
 
    
 Further tests involve Nextcloud account management.  Nextcloud is
-installed on core as described in Configure Nextcloud.  Once
+installed on core as described in Configure Nextcloud.  Once
 /Nextcloud/ is created, ./inst config core will validate
 or update its configuration files.
 
    
@@ -8346,8 +8377,8 @@ with the ./inst client command.
 
    
 
    
 
    
-
    
-
    13.6. Test New Command
    
+
    
+
    13.6. Test New Command
    
 
    
 
    
 A member must be enrolled so that a member's client machine can be
@@ -8367,8 +8398,8 @@ Take note of Dick's initial password.
 
    
 
    
 
    
-
    
-
    13.7. The Test Member Notebook
    
+
    
+
    13.7. The Test Member Notebook
    
 
    
 
    
 A test member's notebook is created next, much like the servers,
@@ -8396,7 +8427,7 @@ behind) the access point.
 
    
 
 
    
-Debian is installed much as detailed in A Test Machine except that
+Debian is installed much as detailed in A Test Machine except that
 the SSH server option is not needed and the GNOME desktop option
 is.  When the machine reboots, the administrator logs into the
 desktop and installs a couple additional software packages (which
@@ -8409,8 +8440,8 @@ require several more).
 
    
 
    
 
    
-
    
-
    13.8. Test Client Command
    
+
    
+
    13.8. Test Client Command
    
 
    
 
    
 The ./inst client command is used to register the public key of a
@@ -8438,11 +8469,11 @@ command, generating campus.conf and public.conf files.
 
    
 
    
 
    
-
    
-
    13.9. Test Campus WireGuard™ Subnet
    
+
    
+
    13.9. Test Campus WireGuard™ Subnet
    
 
    
 
    
-The campus.conf WireGuard™ configuration file (generated in Test
+The campus.conf WireGuard™ configuration file (generated in Test
 Client Command) is transferred to dick, which is at the Wi-Fi access
 point's IP address, host 2 on the wild Ethernet.
 
    
@@ -8483,8 +8514,8 @@ host www
 
    
 
    
 
    
-
    
-
    13.10. Test Web Pages
    
+
    
+
    13.10. Test Web Pages
    
 
    
 
    
 Next, the administrator copies Backup/WWW/ (included in the
@@ -8523,8 +8554,8 @@ will warn but allow the luser to continue.
 
    
 
    
 
    
-
    
-
    13.11. Test Web Update
    
+
    
+
    13.11. Test Web Update
    
 
    
 
    
 Modify /WWW/live/index.html on core and wait 15 minutes for it to
@@ -8538,8 +8569,8 @@ Hack /home/www/index.html on front and observe the result at
 
    
 
    
 
    
-
    
-
    13.12. Test Nextcloud
    
+
    
+
    13.12. Test Nextcloud
    
 
    
 
    
 Nextcloud is typically installed and configured after the first
@@ -8547,9 +8578,9 @@ Ansible run, when core has Internet access via gate.
 installation directory /Nextcloud/nextcloud/ appears, the Ansible
 code skips parts of the Nextcloud configuration.  The same
 installation (or restoration) process used on Core is used on core
-to create /Nextcloud/.  The process starts with Create
-/Nextcloud/, involves Restore Nextcloud or Install Nextcloud,
-and runs ./inst config core again 8.23.6.  When the ./inst
+to create /Nextcloud/.  The process starts with Create
+/Nextcloud/, involves Restore Nextcloud or Install Nextcloud,
+and runs ./inst config core again 8.23.6.  When the ./inst
 config core command is happy with the Nextcloud configuration on
 core, the administrator uses Dick's notebook to test it, performing
 the following tests on dick's desktop.
@@ -8627,8 +8658,8 @@ the calendar.
 
 
    
 
    
-
    
-
    13.13. Test Email
    
+
    
+
    13.13. Test Email
    
 
    
 
    
 With Evolution running on the member notebook dick, one second email
@@ -8656,8 +8687,8 @@ Outgoing email is also tested.  A message to
 
    
 
    
 
    
-
    
-
    13.14. Test Public VPN
    
+
    
+
    13.14. Test Public VPN
    
 
    
 
    
 At this point, dick can move abroad, from the campus Wi-Fi
@@ -8715,8 +8746,8 @@ calendar events.
 
    
 
    
 
    
-
    
-
    13.15. Test Pass Command
    
+
    
+
    13.15. Test Pass Command
    
 
    
 
    
 To test the ./inst pass command, the administrator logs in to core
@@ -8763,8 +8794,8 @@ Finally, the administrator verifies that dick can login on co
 
    
 
    
 
    
-
    
-
    13.16. Test Old Command
    
+
    
+
    13.16. Test Old Command
    
 
    
 
    
 One more institute command is left to exercise.  The administrator
@@ -8784,16 +8815,16 @@ fail.
 
    
 
    
 
    
-
    
-
    14. Future Work
    
+
    
+
    14. Future Work
    
 
    
 
    
 The small institute's network, as currently defined in this doocument,
 is lacking in a number of respects.
 
    
 
    
-
    
-
    14.1. Deficiencies
    
+
    
+
    14.1. Deficiencies
    
 
    
 
    
 The current network monitoring is rudimentary.  It could use some
@@ -8819,16 +8850,16 @@ not available on Front, yet.
 
    
 
    
 
    
-
    
-
    14.2. More Tests
    
+
    
+
    14.2. More Tests
    
 
    
 
    
 The testing process described in the previous chapter is far from
 complete.  Additional tests are needed.
 
    
 
    
-
    
-
    14.2.1. Backup
    
+
    
+
    14.2.1. Backup
    
 
    
 
    
 The backup command has not been tested.  It needs an encrypted
@@ -8837,8 +8868,8 @@ partition with which to sync?  And then some way to compare that to
 
    
 
    
 
    
-
    
-
    14.2.2. Restore
    
+
    
+
    14.2.2. Restore
    
 
    
 
    
 The restore process has not been tested.  It might just copy Backup/
@@ -8848,8 +8879,8 @@ perhaps permissions too.  It could also use an example
 
    
 
    
 
    
-
    
-
    14.2.3. Campus Disconnect
    
+
    
+
    14.2.3. Campus Disconnect
    
 
    
 
    
 Email access (IMAPS) on front is… difficult to test unless
@@ -8873,8 +8904,8 @@ could be used.
 
    
 
    
 
    
-
    
-
    15. Appendix: The Bootstrap
    
+
    
+
    15. Appendix: The Bootstrap
    
 
    
 
    
 Creating the private network from whole cloth (machines with recent
@@ -8894,11 +8925,11 @@ etc.: quite a bit of temporary, manual localnet configuration just to
 get to the additional packages.
 
    
 
    
-
    
-
    15.1. The Current Strategy
    
+
    
+
    15.1. The Current Strategy
    
 
    
 
    
-The strategy pursued in The Hardware is two phase: prepare the servers
+The strategy pursued in The Hardware is two phase: prepare the servers
 on the Internet where additional packages are accessible, then connect
 them to the campus facilities (the private Ethernet switch, Wi-Fi AP,
 ISP), manually configure IP addresses (while the DHCP client silently
@@ -8906,8 +8937,8 @@ fails), and avoid names until BIND9 is configured.
 
    
 
    
 
    
-
    
-
    15.2. Starting With Gate
    
+
    
+
    15.2. Starting With Gate
    
 
    
 
    
 The strategy of Starting With Gate concentrates on configuring Gate's
@@ -8951,8 +8982,8 @@ ansible-playbook -l core site.yml
 
 
    
 
    
-
    
-
    15.3. Pre-provision With Ansible
    
+
    
+
    15.3. Pre-provision With Ansible
    
 
    
 
    
 A refinement of the current strategy might avoid the need to maintain
@@ -9005,7 +9036,7 @@ routes on Front and Gate, making the simulation less… similar.
 
    
 
    
 
    Author: Matt Birkholz
    
-
    Created: 2025-06-15 Sun 19:03
    
+
    Created: 2025-06-28 Sat 10:50
    
 
    Validate
    
 
    
 
-- 
2.25.1