From: Matt Birkholz Date: Fri, 2 Jan 2026 22:07:34 +0000 (-0700) Subject: Update README.html. X-Git-Url: https://birchwood-abbey.net/git?a=commitdiff_plain;h=refs%2Fheads%2Fmain;p=Institute Update README.html. --- diff --git a/README.html b/README.html index 2a72a89..1ee14ee 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,27 +356,38 @@ directories.
 

 
 

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

+

+
+

+In version 2.4 (Debian 13), this variable was split in two.
+

+
+

+dovecot-maildir
mail_driver = maildir
+mail_path = ~/Maildir
 

 

 
 

 The complete Dovecot configurations for Front and Core use these
-common settings with host specific settings for ssl_cert and
-ssl_key.
+common settings with host specific settings for ssl_server_cert_file
+and ssl_server_key_file, ssl_cert and ssl_key on versions of
+Dovecot before 2.4 (Debian 13).
-
-

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 +442,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 +464,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 +487,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 +497,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 +522,8 @@ account is created on Front as well.

-
-

3.6. Keys

+
+

3.6. Keys

The institute keeps its "master secrets" in an encrypted @@ -527,7 +538,7 @@ commands will work.

Chief among the institute's master secrets is the SSH key authorized to access privileged accounts on all of the institute servers. It -is stored in Secret/ssh_admin/id_rsa. The complete list of the +is stored in Secret/ssh_admin/id_ed25519. The complete list of the institute's SSH keys:

@@ -536,10 +547,6 @@ institute's SSH keys: Administrator.
Secret/ssh_monkey/
The key pair used by Monkey to update the website on Front (and other unprivileged tasks).
-
Secret/ssh_front/
The host key pair used by Front to -authenticate itself. The automatically generated key pair is -not used. (Thus Core's configuration does not depend on -Front's.)

@@ -597,8 +604,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 +641,7 @@ files mentioned in the Nextcloud database dump).

-private/backup
#!/bin/bash -e
+private/backup
#!/bin/bash -e
 #
 # DO NOT EDIT.
 #
@@ -738,8 +745,8 @@ finish
-
-

4. The Particulars

+
+

4. The Particulars

This chapter introduces Ansible variables intended to simplify @@ -751,13 +758,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 @@ -796,8 +803,8 @@ domain_priv: small.private

-
-

4.2. Subnets

+
+

4.2. Subnets

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

-
+

=> 10.62.17.0/24

@@ -910,7 +917,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).

@@ -931,7 +938,7 @@ e.g. _net_and_mask rather than _net_cidr.

-network-vars
private_net:
+network-vars
private_net:
            "{{ private_net_cidr | ansible.utils.ipaddr('network') }}"
 private_net_mask:
            "{{ private_net_cidr | ansible.utils.ipaddr('netmask') }}"
@@ -973,7 +980,7 @@ the institute's Internet domain name.
 

 
 

-public/vars.yml
front_addr: 192.168.15.4
+public/vars.yml
front_addr: 192.168.15.4
 

 

 
@@ -991,7 +998,7 @@ with address-vars in the default/main.yml files.
 

 
 

-address-vars

+address-vars

 core_addr_cidr:  "{{ private_net_cidr | ansible.utils.ipaddr('1') }}"
 gate_addr_cidr:  "{{ private_net_cidr | ansible.utils.ipaddr('2') }}"
 gate_wild_addr_cidr:
@@ -1014,63 +1021,83 @@ core_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 on the Internets. It needs only as much disk as required by the institute's public web site. Often the cheapest offering (4GB RAM, 1 core, 20GB disk) is sufficient. The provider should make it easy and -fast to (re)initialize the machine to a factory fresh Debian Server, +fast to (re)initialize the machine to a factory fresh Debian Server and install additional Debian software packages. Indeed it should be 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. +The following example prepared a Digital Ocean droplet to be Front. The institute administrator opened an account at Digital Ocean, registered an ssh key, and used a Digital Ocean control panel to create a new machine (again, one of the cheapest, smallest available) -with Ubuntu Server 20.04LTS installed. Once created, the machine and -its IP address (159.65.75.60) appeared on the panel. Using that +with Debian 13 installed. Once created, the machine and its IP +address (159.65.75.60) appeared on the panel. Using that address, the administrator logged into the new machine with ssh.

-On the administrator's notebook (in a terminal): +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 +first thing the administrator did was to create a sysadm account. +

+ +

+The password for the sysadm account was generated by gpw, saved in +the administrator's password keep, and added to Secret/become.yml as +shown below. (Producing a working Ansible configuration with +Secret/become.yml file is described in The Ansible Configuration.) 

-notebook$ ssh root@159.65.75.60
-root@ubuntu# 
+notebook$ gpw 1 16
+givitysticangout
+notebook$ echo -n "become_front: " >>Secret/become.yml
+notebook$ ansible-vault encrypt_string givitysticangout \
+notebook_     >>Secret/become.yml
+notebook$

-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 -administrator created a sysadm account with the ability to request -escalated privileges via the sudo command. +With the new sysadm password saved, the administrator logged in as +root, created the sysadm account, and authorized it to request +elevated privileges via the sudo command.

+

+On the administrator's notebook (in a terminal): +

-root@ubuntu# adduser sysadm
+notebook$ H=159.65.75.60
+notebook$ ssh root@$H
+The authenticity of host '159.65.75.60' can't be established.
+....
+Are you sure you want to continue connecting (...)? yes
+root@front# adduser sysadm
 ...
 New password: givitysticangout
 Retype new password: givitysticangout
@@ -1078,79 +1105,49 @@ Retype new password: givitysticangout
         Full Name []: System Administrator
 ...
 Is the information correct? [Y/n] 
-root@ubuntu# adduser sysadm sudo
-root@ubuntu# logout
+root@front# adduser sysadm sudo
+root@front# logout
 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.) -

- -
-notebook$ gpw 1 16
-givitysticangout
-notebook$ echo -n "become_front: " >>Secret/become.yml
-notebook$ ansible-vault encrypt_string givitysticangout \
-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. 

-notebook$ cat ~/.ssh/id_rsa.pub Secret/ssh_admin/id_rsa.pub \
+notebook$ cat ~/.ssh/id_ed25519.pub \
+notebook_     Secret/ssh_admin/id_ed25519.pub \
 notebook_     > admin_keys
-notebook$ scp admin_keys sysadm@159.65.75.60:
-The authenticity of host '159.65.75.60' can't be established.
-....
-Are you sure you want to continue connecting (...)? yes
-...
-sysadm@159.65.75.60's password: givitysticangout
-notebook$ ssh sysadm@159.65.75.60
-sysadm@159.65.75.60's password: givitysticangout
-sysadm@ubuntu$ ( umask 077; mkdir .ssh; \
-sysadm@ubuntu_   cp admin_keys .ssh/authorized_keys; \
-sysadm@ubuntu_   rm admin_keys )
-sysadm@ubuntu$ logout
+notebook$ scp admin_keys root@$H:
+notebook$ ssh root@$H
+root@front# mkdir ~sysadm/.ssh
+root@front# mv admin_keys ~sysadm/.ssh/authorized_keys
+root@front# chmod -R g=,o= ~sysadm/.ssh
+root@front# chown -R sysadm:sysadm ~sysadm/.ssh
+root@front# logout
 notebook$ rm admin_keys
 notebook$

-The Ansible configuration expects certain host keys on the new front. -The administrator should install them now, and deal with the machine's -change of SSH identity. The following commands copied the host keys -in Secret/ssh_front/ to the droplet and restarted the SSH server. +After installing authorized keys, the administrator verified that +password-less ssh logins work, then disabled root logins and tested +that they were indeed denied. 

-notebook$ ( cd Secret/ssh_front/etc/ssh/;
-notebook_   scp ssh_host_* sysadm@159.65.75.60: )
-notebook$ ssh sysadm@159.65.75.60
-sysadm@ubuntu$ chmod 600 ssh_host_*
-sysadm@ubuntu$ chmod 644 ssh_host_*.pub
-sysadm@ubuntu$ sudo cp -b ssh_host_* /etc/ssh/
-sysadm@ubuntu$ sudo systemctl restart ssh
-sysadm@ubuntu$ logout
-notebook$ ssh-keygen -f ~/.ssh/known_hosts -R 159.65.75.60
+notebook$ ssh sysadm@$H
+sysadm@front$ sudo rm -r /root/.ssh
+sysadm@front$ logout
+notebook$ ssh root@$H
+root@159.65.75.60: Permission denied (publickey).
+notebook$
-

-The last command removed the old host key from the administrator's -known_hosts file. The next few commands served to test -password-less login as well as the privilege escalation command -sudo. -

-

The Droplet needed a couple additional software packages immediately. The wireguard package was needed to generate the Droplet's private @@ -1158,58 +1155,74 @@ key. The systemd-resolved package was installed so that the subsequent reboot gets ResolveD configured properly (else resolvectl hangs, causing wg-quick@wg0 to hang…). The rest are included just to speed up (re)testing of "prepared" test machines, e.g. prepared as -described in The Test Front Machine. +described in The Test Front Machine. 

-notebook$ ssh sysadm@159.65.75.60
-sysadm@ubuntu$ sudo apt install wireguard systemd-resolved \
+notebook$ ssh sysadm@$H
+sysadm@front$ sudo apt update
+sysadm@front$ sudo apt full-upgrade --autoremove
+sysadm@front$ sudo apt install wireguard systemd-resolved \
     unattended-upgrades postfix dovecot-imapd rsync apache2 kamailio
+sysadm@front$
+

+Manual installation of Postfix prompted for configuration type and +mail name. The answers given are listed here. +

+ +
    +
  • General type of mail configuration: 2 (Internet Site)
    • +
  • System mail name: small.example.org (i.e. domain_name)
    • +
+

With WireGuard™ installed, the following commands generated a new private key, and displayed its public key. 

-sysadm@ubuntu$ umask 077
-susadm@ubuntu$ wg genkey \
-sysadm@ubuntu_ | sudo tee /etc/wireguard/private-key \
-sysadm@ubuntu_ | wg pubkey
+sysadm@front$ umask 077
+susadm@front$ wg genkey \
+sysadm@front_ | sudo tee /etc/wireguard/private-key \
+sysadm@front_ | wg pubkey
 S+6HaTnOwwhWgUGXjSBcPAvifKw+j8BDTRfq534gNW4=
+sysadm@front$ logout
+notebook$

The public key is copied and pasted into private/vars.yml as the -value of front_wg_pubkey (as in the example here). +value of front_wg_pubkey (as in the example here).

-After collecting Front's public key, the administrator disabled root -logins on the droplet. The last command below tested that root logins -were indeed denied. +The prospective IP address (159.65.75.60) is also pasted into +public/vars.yml as the value of front_addr (as in the example +here). +

+ +

+Finally, the new machine's ssh public host is copied to +private/front_ed25519_key.pub. 

-sysadm@ubuntu$ sudo rm -r /root/.ssh
-sysadm@ubuntu# logout
-notebook$ ssh root@159.65.75.60
-root@159.65.75.60: Permission denied (publickey).
-notebook$ 
+notebook$ scp sysadm@$H:/etc/ssh/ssh_host_ed25519_key.pub \
+notebook_     private/front_ed25519_key.pub
+notebook$

-At this point the droplet was ready for configuration by Ansible. -Later, provisioned with all of Front's services and tested, the -institute's domain name was changed, making 159.65.75.60 its new -address. +At this point Front was prepared for provisioning with Ansible (and +Ansible prepared for the droplet!).

-
-

5.2. The Core Machine

+
+

5.2. The Core Machine

Core is the small institute's private file, email, cloud and whatnot @@ -1233,7 +1246,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). 

@@ -1249,7 +1262,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.)
 

 
 
@@ -1313,13 +1326,14 @@ _                  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.
 

 
 
-notebook$ cat ~/.ssh/id_rsa.pub Secret/ssh_admin/id_rsa.pub \
+notebook$ cat ~/.ssh/id_ed25519.pub \
+notebook_     Secret/ssh_admin/id_ed25519.pub \
 notebook_     > admin_keys
 notebook$ scp admin_keys sysadm@core.lan:
 The authenticity of host 'core.lan' can't be established.
@@ -1353,7 +1367,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.
@@ -1365,12 +1379,12 @@ sysadm@core$ sudo ip route add default via 10.227.248.2 dev enp82s0
 

 
 

-At this point Core was ready for provisioning with Ansible.
+At this point Core was prepared 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 @@ -1390,7 +1404,7 @@ modem, a USB port tethered to a phone, a wireless adapter connected to a campground Wi-Fi access point, etc. -

+
 =============== | ==================================================
                 |                                           Premises
           (Campus ISP)                                              
@@ -1403,8 +1417,8 @@ connected to a 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 @@ -1413,7 +1427,7 @@ This avoids the need for a second Wi-Fi access point and leads to the following topology.

-
+
 =============== | ==================================================
                 |                                           Premises
            (House ISP)                                              
@@ -1437,12 +1451,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.

@@ -1451,7 +1465,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). 

@@ -1467,7 +1481,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.)
 

 
 
@@ -1499,13 +1513,14 @@ ready to proceed.
 
 

 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.
 

 
 
-notebook$ cat ~/.ssh/id_rsa.pub Secret/ssh_admin/id_rsa.pub \
+notebook$ cat ~/.ssh/id_ed25519.pub \
+notebook_     Secret/ssh_admin/id_ed25519.pub \
 notebook_     > admin_keys
 notebook$ scp admin_keys sysadm@gate.lan:
 The authenticity of host 'gate.lan' can't be established.
@@ -1539,7 +1554,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.
 

 
 
@@ -1551,32 +1566,32 @@ Gate was also connected to the USB Ethernet dongles cabled to the
 campus Wi-Fi access point and the campus ISP and the values of three
 variables (gate_lan_mac, gate_wild_mac, and gate_isp_mac in
 private/vars.yml) match the actual hardware MAC addresses of the
-dongles.  (For more information, see the tasks in section 9.3.)
+dongles.  (For more information, see the tasks in section 9.3.)
 

 
 

-At this point Gate was ready for provisioning with Ansible.
+At this point Gate was prepared 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.

@@ -1589,8 +1604,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 @@ -1659,14 +1674,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.

@@ -1693,15 +1708,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.)

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

-
-

7.1. Role Defaults

+
+

7.1. Role Defaults

The front role sets a number of variables to default values in its @@ -1735,15 +1750,15 @@ The front role sets a number of variables to default values in its

The membership-rolls reference defines membership_rolls which is used to select an empty membership roll if one has not been written -yet. (See section 12.7.) +yet. (See section 12.7.)

-
-

7.2. Include Particulars

+
+

7.2. 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.

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

7.3. Configure Hostname

+
+

7.3. Configure Hostname

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

-
-

7.4. Add Administrator to System Groups

+
+

7.4. Add Administrator to System Groups

The administrator often needs to read (directories of) log files owned @@ -1813,56 +1828,16 @@ these groups speeds up debugging.

-
-

7.5. Configure SSH

+
+

7.5. Configure Monkey

-The SSH service on Front needs to be known to Monkey. The following -tasks ensure this by replacing the automatically generated keys with -those stored in Secret/ssh_front/etc/ssh/ and restarting the server. -

- -
-roles_t/front/tasks/main.yml

-- name: Install SSH host keys.
-  become: yes
-  copy:
-    src: ../Secret/ssh_front/etc/ssh/{{ item.name }}
-    dest: /etc/ssh/{{ item.name }}
-    mode: "{{ item.mode }}"
-  loop:
-  - { name: ssh_host_ecdsa_key,       mode: "u=rw,g=,o=" }
-  - { name: ssh_host_ecdsa_key.pub,   mode: "u=rw,g=r,o=r" }
-  - { name: ssh_host_ed25519_key,     mode: "u=rw,g=,o=" }
-  - { name: ssh_host_ed25519_key.pub, mode: "u=rw,g=r,o=r" }
-  - { name: ssh_host_rsa_key,         mode: "u=rw,g=,o=" }
-  - { name: ssh_host_rsa_key.pub,     mode: "u=rw,g=r,o=r" }
-  notify: Reload SSH server.
-
-
- -
-roles_t/front/handlers/main.yml
---
-- name: Reload SSH server.
-  become: yes
-  systemd:
-    service: ssh
-    state: reloaded
-  tags: actualizer
-
-
-
-
-
-

7.6. 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. Monkey on Core will login as monkey on Front to synchronize the files (as -described in *Configure Apache2). To do that without needing a +described in *Configure Apache2). To do that without needing a password, the monkey account on Front should authorize Monkey's SSH key on Core.

@@ -1877,11 +1852,9 @@ key on Core. - name: Authorize monkey@core. become: yes - vars: - pubkeyfile: ../Secret/ssh_monkey/id_rsa.pub authorized_key: user: monkey - key: "{{ lookup('file', pubkeyfile) }}" + key: "{{ lookup('file', '../Secret/ssh_monkey/id_ed25519.pub') }}" manage_dir: yes - name: Add {{ ansible_user }} to monkey group. @@ -1894,9 +1867,9 @@ key on Core.
-
-

7.7. Install Rsync

-
+
+

7.6. Install Rsync

+

Monkey uses Rsync to keep the institute's public web site up-to-date.

@@ -1910,9 +1883,9 @@ Monkey uses Rsync to keep the institute's public web site up-to-date.
-
-

7.8. Install Unattended Upgrades

-
+
+

7.7. Install Unattended Upgrades

+

The institute prefers to install security updates as soon as possible.

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

7.9. 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.

@@ -1970,14 +1943,13 @@ recipient" replies. The Account Management chapter de
-
-

7.10. Install Server Certificate

-
+
+

7.9. Install Server Certificate

+

The servers on Front use the same certificate (and key) to -authenticate themselves to institute clients. They share the -/etc/server.crt and /etc/server.key files, the latter only -readable by root. +authenticate to institute clients. They share the /etc/server.crt +and /etc/server.key files, the latter only readable by root.

@@ -1985,25 +1957,26 @@ readable by root. - name: Install server certificate/key. become: yes copy: - src: ../Secret/CA/pki/{{ item.path }}.{{ item.typ }} - dest: /etc/server.{{ item.typ }} + src: "{{ item.src }}" + dest: "{{ item.dest }}" mode: "{{ item.mode }}" force: no loop: - - { path: "issued/{{ domain_name }}", typ: crt, - mode: "u=r,g=r,o=r" } - - { path: "private/{{ domain_name }}", typ: key, - mode: "u=r,g=,o=" } + - src: "../Secret/CA/pki/issued/{{ domain_name }}.crt" + dest: "/etc/server.crt" + mode: "u=r,g=r,o=r" + - src: "../Secret/CA/pki/private/{{ domain_name }}.key" + dest: "/etc/server.key" + mode: "u=r,g=,o=" notify: - - Restart Postfix. - Restart Dovecot.
-
-

7.11. Configure Postfix on Front

-
+
+

7.10. Configure Postfix on Front

+

Front uses Postfix to provide the institute's public SMTP service, and uses the institute's domain name for its host name. The default @@ -2019,7 +1992,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 @@ -2032,7 +2005,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
@@ -2048,7 +2021,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
@@ -2069,13 +2042,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
 

 

@@ -2087,7 +2060,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>>
@@ -2145,7 +2118,7 @@ start and enable the service.
 

 
 

-roles_t/front/handlers/main.yml

+roles_t/front/handlers/main.yml
---
 - name: Restart Postfix.
   become: yes
   systemd:
@@ -2163,9 +2136,9 @@ start and enable the service.
-
-

7.12. Configure Public Email Aliases

-
+
+

7.11. Configure Public Email Aliases

+

The institute's Front needs to deliver email addressed to a number of common aliases as well as those advertised on the web site. System @@ -2206,9 +2179,9 @@ created by a more specialized role.

-
-

7.13. Configure Dovecot IMAPd

-
+
+

7.12. Configure Dovecot IMAPd

+

Front uses Dovecot's IMAPd to allow user Fetchmail jobs on Core to pick up messages. Front's Dovecot configuration is largely the Debian @@ -2216,7 +2189,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.

@@ -2240,7 +2213,7 @@ and enables it to start at every reboot. become: yes apt: pkg=dovecot-imapd -- name: Configure Dovecot IMAPd. +- name: Configure Dovecot 2.3 IMAPd. become: yes copy: content: | @@ -2248,8 +2221,26 @@ and enables it to start at every reboot. ssl_cert = </etc/server.crt ssl_key = </etc/server.key <<dovecot-ports>> + <<dovecot-2.3-maildir>> + dest: /etc/dovecot/local.conf + when: ansible_distribution != 'Debian' + or ( ansible_distribution == 'Debian' + and 13 > ansible_distribution_major_version|int ) + notify: Restart Dovecot. + +- name: Configure Dovecot IMAPd. + become: yes + copy: + content: | + <<dovecot-tls>> + ssl_server_cert_file = /etc/server.crt + ssl_server_key_file = /etc/server.key + <<dovecot-ports>> <<dovecot-maildir>> dest: /etc/dovecot/local.conf + when: + - ansible_distribution == 'Debian' + - 12 < ansible_distribution_major_version|int notify: Restart Dovecot. - name: Start Dovecot. @@ -2279,9 +2270,9 @@ and enables it to start at every reboot.
-
-

7.14. Configure Apache2

-
+
+

7.13. Configure Apache2

+

This is the small institute's public web site. It is simple, static, and thus (hopefully) difficult to subvert. There are no server-side @@ -2316,7 +2307,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',
@@ -2371,7 +2362,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
@@ -2386,7 +2377,7 @@ HTTPS URLs.
 

 
 

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

@@ -2411,7 +2402,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
@@ -2578,9 +2569,9 @@ the users' ~/Public/HTML/ directories.
 

 

 

-

-
7.15. Configure Public WireGuard™ Subnet

-

+

+
7.14. Configure Public WireGuard™ Subnet

+

 

 Front uses WireGuard™ to provide a public (Internet accessible) VPN
 service.  Core has an interface on this VPN and is expected to forward
@@ -2663,9 +2654,9 @@ The "empty" WireGuard™ configuration file (below) is used until the
-
-

7.15.1. Example private/front-wg0.conf

-
+
+

7.14.1. Example private/front-wg0.conf

+

The example private/front-wg0.conf below recognizes Core by its public key and routes the institute's private networks to it. It also @@ -2731,9 +2722,9 @@ WireGuard™ tunnel on Dick's notebook, used abroad
-
-

7.16. Configure Kamailio

-
+
+

7.15. Configure Kamailio

+

Front uses Kamailio to provide a SIP service on the public VPN so that members abroad can chat privately. This is a connection-less UDP @@ -2754,7 +2745,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
@@ -2810,7 +2801,6 @@ not be started before the wg0 device has appeared. become: yes systemd: daemon-reload: yes - tags: actualizer
@@ -2856,22 +2846,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. Role Defaults

+
+

8.1. Role Defaults

-As in The Front Role, the core role sets a number of variables to +As in The Front Role, the core role sets a number of variables to default values in its defaults/main.yml file.

@@ -2884,11 +2874,11 @@ default values in its defaults/main.yml file.
-
-

8.2. Include Particulars

+
+

8.2. 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.

@@ -2909,8 +2899,8 @@ particulars and membership roll.
-
-

8.3. Configure Hostname

+
+

8.3. Configure Hostname

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

-
-

8.4. Configure Systemd Resolved

+
+

8.4. Configure Systemd Resolved

Core runs the campus name server, so Resolved is configured to use it @@ -2964,7 +2954,6 @@ list, and to disable its cache and stub listener. - { regexp: '^ *Cache *=', line: "Cache=no" } - { regexp: '^ *DNSStubListener *=', line: "DNSStubListener=no" } notify: - - Reload Systemd. - Restart Systemd resolved.

@@ -2975,7 +2964,6 @@ list, and to disable its cache and stub listener. become: yes systemd: daemon-reload: yes - tags: actualizer - name: Restart Systemd resolved. become: yes @@ -2987,8 +2975,8 @@ list, and to disable its cache and stub listener.
-
-

8.5. Configure Core NetworkD

+
+

8.5. Configure Core NetworkD

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

-
-

8.6. Configure DHCP For the Private Ethernet

+
+

8.6. Configure DHCP For the Private Ethernet

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

-
-

8.7. Configure BIND9

+
+

8.7. 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.

@@ -3241,7 +3229,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 }};
@@ -3272,7 +3260,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;
@@ -3384,8 +3372,8 @@ $TTL    7200
-
-

8.8. Add Administrator to System Groups

+
+

8.8. Add Administrator to System Groups

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

-
-

8.9. Configure Monkey

+
+

8.9. 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).

@@ -3451,18 +3439,16 @@ described in *Configure Apache2). owner: monkey group: monkey loop: - - { name: config, mode: "u=rw,g=r,o=" } - - { name: id_rsa.pub, mode: "u=rw,g=r,o=r" } - - { name: id_rsa, mode: "u=rw,g=,o=" } + - { name: config, mode: "u=rw,g=r,o=" } + - { name: id_ed25519.pub, mode: "u=rw,g=r,o=r" } + - { name: id_ed25519, mode: "u=rw,g=,o=" } - name: Configure Monkey SSH known hosts. become: yes vars: - pubkeypath: ../Secret/ssh_front/etc/ssh - pubkeyfile: "{{ pubkeypath }}/ssh_host_ecdsa_key.pub" - pubkey: "{{ lookup('file', pubkeyfile) }}" + pubkey: "{{ lookup('file', '../private/front_ed25519_key.pub') }}" lineinfile: - regexp: "^{{ domain_name }},{{ front_addr }} ecdsa-sha2-nistp256 " + regexp: "^{{ domain_name }},{{ front_addr }} ssh-ed25519 " line: "{{ domain_name }},{{ front_addr }} {{ pubkey }}" path: /home/monkey/.ssh/known_hosts create: yes @@ -3473,8 +3459,8 @@ described in *Configure Apache2).
-
-

8.10. Install Unattended Upgrades

+
+

8.10. Install Unattended Upgrades

The institute prefers to install security updates as soon as possible. @@ -3489,12 +3475,12 @@ The institute prefers to install security updates as soon as possible.

-
-

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.

@@ -3532,12 +3518,12 @@ 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 -themselves to institute clients. They share the /etc/server.crt and +to institute clients. They share the /etc/server.crt and /etc/server.key files, the latter only readable by root.

@@ -3546,23 +3532,25 @@ themselves to institute clients. They share the /etc/server.crt and - name: Install server certificate/key. become: yes copy: - src: ../Secret/CA/pki/{{ item.path }}.{{ item.typ }} - dest: /etc/server.{{ item.typ }} + src: "{{ item.src }}" + dest: "{{ item.dest }}" mode: "{{ item.mode }}" + force: no loop: - - { path: "issued/core.{{ domain_priv }}", typ: crt, - mode: "u=r,g=r,o=r" } - - { path: "private/core.{{ domain_priv }}", typ: key, - mode: "u=r,g=,o=" } + - src: "../Secret/CA/pki/issued/core.{{ domain_priv }}.crt" + dest: "/etc/server.crt" + mode: "u=r,g=r,o=r" + - src: "../Secret/CA/pki/private/core.{{ domain_priv }}.key" + dest: "/etc/server.key" + mode: "u=r,g=,o=" notify: - - Restart Postfix. - Restart Dovecot.
-
-

8.13. Install Chrony

+
+

8.13. Install Chrony

Core uses Chrony to provide a time synchronization service to the campus. @@ -3598,8 +3586,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 @@ -3615,7 +3603,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 @@ -3628,7 +3616,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 }}
@@ -3644,7 +3632,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 }}]" }
 

 

 
@@ -3656,7 +3644,7 @@ file.
 

 
 

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

 

@@ -3667,7 +3655,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>>
@@ -3745,8 +3733,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 @@ -3783,8 +3771,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 @@ -3794,7 +3782,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.

@@ -3802,7 +3790,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.)

@@ -3817,15 +3805,32 @@ and enables it to start at every reboot. become: yes apt: pkg=dovecot-imapd -- name: Configure Dovecot IMAPd. +- name: Configure Dovecot 2.3 IMAPd. become: yes copy: content: | <<dovecot-tls>> ssl_cert = </etc/server.crt ssl_key = </etc/server.key + <<dovecot-2.3-maildir>> + dest: /etc/dovecot/local.conf + when: ansible_distribution != 'Debian' + or ( ansible_distribution == 'Debian' + and 13 > ansible_distribution_major_version|int ) + notify: Restart Dovecot. + +- name: Configure Dovecot IMAPd. + become: yes + copy: + content: | + <<dovecot-tls>> + ssl_server_cert_file = /etc/server.crt + ssl_server_key_file = /etc/server.key <<dovecot-maildir>> dest: /etc/dovecot/local.conf + when: + - ansible_distribution == 'Debian' + - 12 < ansible_distribution_major_version|int notify: Restart Dovecot. - name: Start Dovecot. @@ -3855,8 +3860,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 @@ -3873,7 +3878,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
@@ -3892,7 +3897,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
@@ -3950,6 +3955,7 @@ provided the Core service.
   when:
   - members[item].status == 'current'
   - members[item].password_fetchmail is defined
+  notify: Reload Systemd.
   tags: accounts
 
 - name: Enable/Start user fetchmail services.
@@ -3962,7 +3968,8 @@ provided the Core service.
   when:
   - members[item].status == 'current'
   - members[item].password_fetchmail is defined
-  tags: accounts, actualizer
+  notify: Reload Systemd.
+  tags: accounts
 

 

 
@@ -4004,17 +4011,18 @@ Otherwise the following task might be appropriate.
   when:
   - members[item].status != 'current'
   - members[item].password_fetchmail is defined
+  notify: Reload Systemd.
   tags: accounts
-
-

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.

@@ -4085,7 +4093,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
@@ -4100,7 +4108,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 }}
@@ -4127,7 +4135,7 @@ familiar.
 

 
 

-apache-test
<VirtualHost *:80>
+apache-test
<VirtualHost *:80>
         ServerName test
         ServerAlias test.{{ domain_priv }}
         ServerAdmin webmaster@core.{{ domain_priv }}
@@ -4156,7 +4164,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 }}
@@ -4280,8 +4288,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
@@ -4290,7 +4298,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.
 #
@@ -4308,7 +4316,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.
 

 
 

@@ -4333,12 +4341,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.
 

@@ -4408,8 +4416,8 @@ service.
 

 

 

-

-
8.21. Configure NAGIOS

+

+
8.21. Configure NAGIOS

 

 

 Core runs a nagios4 server to monitor "services" on institute hosts.
@@ -4498,8 +4506,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 @@ -4574,8 +4582,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 @@ -4687,8 +4695,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 @@ -4705,12 +4713,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 @@ -4841,12 +4849,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.

@@ -4861,20 +4869,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 @@ -5116,8 +5124,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 @@ -5160,8 +5168,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 @@ -5219,8 +5227,8 @@ sudo mount /Nextcloud

-
-

8.23.4. Restore Nextcloud

+
+

8.23.4. Restore Nextcloud

Restoring Nextcloud in the newly created /Nextcloud/ presumably @@ -5279,8 +5287,8 @@ Overview web page.

-
-

8.23.5. Install Nextcloud

+
+

8.23.5. Install Nextcloud

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

-
-

8.23.6. Afterwards

+
+

8.23.6. Afterwards

Whether Nextcloud was restored or installed, there are a few things @@ -5516,8 +5524,6 @@ unedited copy of the parameters SMTP and not by Sendmail nor Qmail. line: " 'mail_sendmailmode' => 'pipe'," - regexp: "^ *'mail_from_address' *=>" line: " 'mail_from_address' => 'webmaster'," - - regexp: "^ *'mail_domain' *=>" - line: " 'mail_domain' => 'core.small.private'," when: nextcloud.stat.exists

@@ -5562,14 +5568,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.

@@ -5591,11 +5597,11 @@ applied first, by which Gate gets a campus machine's DNS and Postfix configurations, etc.

-
-

9.1. Role Defaults

+
+

9.1. Role Defaults

-As in The Core Role, the gate role sets a number of variables to +As in The Core Role, the gate role sets a number of variables to default values in its defaults/main.yml file.

@@ -5607,8 +5613,8 @@ default values in its defaults/main.yml file.
-
-

9.2. Include Particulars

+
+

9.2. Include Particulars

The following should be familiar boilerplate by now. @@ -5625,8 +5631,8 @@ The following should be familiar boilerplate by now.

-
-

9.3. Configure Gate NetworkD

+
+

9.3. Configure Gate NetworkD

Gate's network interfaces are configured using SystemD NetworkD @@ -5647,8 +5653,8 @@ The tasks in the following sections install the necessary configuration files.

-
-

9.3.1. Gate's lan Interface

+
+

9.3.1. Gate's lan Interface

The campus Ethernet interface is named lan and configured by @@ -5699,8 +5705,8 @@ The campus Ethernet interface is named lan and configured by

-
-

9.3.2. Gate's wild Interface

+
+

9.3.2. Gate's wild Interface

The institute keeps the wild ones off the campus Ethernet. Its wild @@ -5781,8 +5787,8 @@ configured by 10-wild.link and 10-wild.network files in

-
-

9.3.3. Gate's isp Interface

+
+

9.3.3. Gate's isp Interface

The interface to the campus ISP is named isp and configured by @@ -5843,8 +5849,8 @@ interface by its MAC address.

-
-

9.4. Configure Gate ResolveD

+
+

9.4. Configure Gate ResolveD

Gate provides name service on the wild Ethernet by having its "stub @@ -5877,7 +5883,6 @@ listener" listen there. That stub should not read /etc/hosts lest become: yes systemd: daemon-reload: yes - tags: actualizer - name: Restart Systemd resolved. become: yes @@ -5889,8 +5894,8 @@ listener" listen there. That stub should not read /etc/hosts lest

-
-

9.5. UFW Rules

+
+

9.5. UFW Rules

Gate uses the Uncomplicated FireWall (UFW) to install its packet @@ -5914,7 +5919,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
@@ -5930,7 +5935,7 @@ connection tracking).

-ufw-forward-nat
-A ufw-before-forward -i lan  -o isp -j ACCEPT
+ufw-forward-nat
-A ufw-before-forward -i lan  -o isp -j ACCEPT
 -A ufw-before-forward -i wild -o isp -j ACCEPT
@@ -5944,7 +5949,7 @@ public and campus VPNs is also allowed.

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

@@ -5963,8 +5968,8 @@ the wild device to the lan device, just the wg0<
-
-

9.6. Configure UFW

+
+

9.6. Configure UFW

The following tasks install the Uncomplicated Firewall (UFW), set its @@ -6016,8 +6021,8 @@ policy in /etc/default/ufw, and install the institute's rules in

-
-

9.7. Configure Campus WireGuard™ Subnet

+
+

9.7. Configure Campus WireGuard™ Subnet

Gate uses WireGuard™ to provide a campus VPN service. Gate's routes @@ -6102,8 +6107,8 @@ The "empty" WireGuard™ configuration file (below) is used until the

-
-

9.7.1. Example private/gate-wg0.conf

+
+

9.7.1. Example private/gate-wg0.conf

The example private/gate-wg0.conf below recognizes a wired IoT @@ -6188,8 +6193,8 @@ WireGuard™ tunnel on Dick's notebook, used on campus
-
-

10. The Campus Role

+
+

10. The Campus Role

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

-
-

10.1. Role Defaults

+
+

10.1. Role Defaults

-As in The Gate Role, the campus role sets a number of variables to +As in The Gate Role, the campus role sets a number of variables to default values in its defaults/main.yml file.

@@ -6221,8 +6226,8 @@ default values in its defaults/main.yml file.
-
-

10.2. Include Particulars

+
+

10.2. Include Particulars

The following should be familiar boilerplate by now. @@ -6239,8 +6244,8 @@ The following should be familiar boilerplate by now.

-
-

10.3. Configure Hostname

+
+

10.3. Configure Hostname

Clients should be using the expected host name. @@ -6268,8 +6273,8 @@ Clients should be using the expected host name.

-
-

10.4. Configure Systemd Timesyncd

+
+

10.4. Configure Systemd Timesyncd

The institute uses a common time reference throughout the campus. @@ -6279,12 +6284,29 @@ and file timestamps.

roles_t/campus/tasks/main.yml

+- name: Install timesyncd.
+  become: yes
+  apt: pkg=systemd-timesyncd
+
 - name: Configure timesyncd.
   become: yes
   lineinfile:
     path: /etc/systemd/timesyncd.conf
     line: NTP=ntp.{{ domain_priv }}
   notify: Restart systemd-timesyncd.
+
+- name: Start timesyncd.
+  become: yes
+  systemd:
+    service: systemd-timesyncd
+    state: started
+  tags: actualizer
+
+- name: Enable timesyncd.
+  become: yes
+  systemd:
+    service: systemd-timesyncd
+    enabled: yes
@@ -6300,8 +6322,8 @@ and file timestamps.
-
-

10.5. Add Administrator to System Groups

+
+

10.5. Add Administrator to System Groups

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

-
-

10.6. Install Unattended Upgrades

+
+

10.6. Install Unattended Upgrades

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

-
-

10.7. Configure Postfix on Campus

+
+

10.7. Configure Postfix on Campus

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

-
-

10.8. Set Domain Name

+
+

10.8. Set Domain Name

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

-
-

10.9. Configure NRPE

+
+

10.9. 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.

@@ -6497,8 +6519,8 @@ Role.
-
-

11. The Ansible Configuration

+
+

11. The Ansible Configuration

The small institute uses Ansible to maintain the configuration of its @@ -6507,7 +6529,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.

@@ -6520,13 +6542,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.

    @@ -6535,7 +6557,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 @@ -6552,8 +6574,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 @@ -6565,10 +6587,10 @@ 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
+    ansible_ssh_extra_args: -i Secret/ssh_admin/id_ed25519
   hosts:
     front:
       ansible_host: 192.168.58.3
@@ -6630,8 +6652,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 @@ -6664,8 +6686,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 @@ -6677,17 +6699,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. @@ -6730,7 +6752,7 @@ would be copied, with appropriate changes, into new subdirectories public/ and private/.

  • ~/network/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.

    @@ -6766,8 +6788,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 @@ -6786,8 +6808,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 @@ -6797,8 +6819,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 @@ -6824,8 +6846,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 @@ -6885,8 +6907,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 @@ -6931,8 +6953,8 @@ The playbook that updates private/vars.pl:

    -
    -

    12.4. The check-inst-vars Role

    +
    +

    12.4. The check-inst-vars Role

    This role is executed by playbooks/check-inst-vars.yml and is not @@ -6983,7 +7005,7 @@ following few provide the servers' public keys and ports.

    -private/vars.yml
    front_wg_pubkey: S+6HaTnOwwhWgUGXjSBcPAvifKw+j8BDTRfq534gNW4=
+private/vars.yml
    front_wg_pubkey: S+6HaTnOwwhWgUGXjSBcPAvifKw+j8BDTRfq534gNW4=
 public_wg_port:  39608
 
 gate_wg_pubkey:  y3cjFnvQbylmH4lGTujpqc8rusIElmJ4Gu9hh6iR7QI=
@@ -6994,8 +7016,8 @@ campus_wg_port:  51820
    -
    -

    12.5. The CA Command

    +
    +

    12.5. The CA Command

    The next code block implements the CA sub-command, which creates a @@ -7076,27 +7098,24 @@ config. mysystem "mkdir Secret/ssh_admin"; chmod 0700, "Secret/ssh_admin"; - mysystem ("ssh-keygen -q -t rsa", + mysystem ("ssh-keygen -q -t ed25519", "-C A\\ Small\\ Institute\\ Administrator", - "-N '' -f Secret/ssh_admin/id_rsa"); + "-N '' -f Secret/ssh_admin/id_ed25519"); mysystem "mkdir Secret/ssh_monkey"; chmod 0700, "Secret/ssh_monkey"; mysystem "echo 'HashKnownHosts no' >Secret/ssh_monkey/config"; - mysystem ("ssh-keygen -q -t rsa -C monkey\@core", - "-N '' -f Secret/ssh_monkey/id_rsa"); - - mysystem "mkdir Secret/ssh_front"; - chmod 0700, "Secret/ssh_front"; - mysystem "ssh-keygen -A -f Secret/ssh_front -C $dom"; + mysystem ("ssh-keygen -q -t ed25519", + "-C monkey\@core.$domain_priv", + "-N '' -f Secret/ssh_monkey/id_ed25519"); exit; }

    -
    -

    12.6. The Config Command

    +
    +

    12.6. The Config Command

    The next code block implements the config sub-command, which @@ -7113,8 +7132,8 @@ Example command lines: 

     ./inst config
 ./inst config -n
-./inst config HOST
-./inst config -n HOST
+./inst config LIMIT
+./inst config -n LIMIT
    @@ -7146,12 +7165,12 @@ Example command lines:
    -
    -

    12.7. Account Management

    +
    +

    12.7. 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. @@ -7217,7 +7236,7 @@ value of membership_rolls.

    -membership-rolls
    
+membership-rolls
    
 membership_rolls:
 - "../private/members.yml"
 - "../private/members-empty.yml"
@@ -7351,8 +7370,8 @@ each record.
    -
    -

    12.8. The New Command

    +
    +

    12.8. The New Command

    The next code block implements the new sub-command. It adds a new @@ -7442,8 +7461,8 @@ initial, generated password.

    -
    -

    12.9. The Pass Command

    +
    +

    12.9. The Pass Command

    The institute's passwd command on Core securely emails root with a @@ -7457,8 +7476,8 @@ Ansible site.yml playbook to update the message is sent to member@core.

    -
    -

    12.9.1. Less Aggressive passwd.

    +
    +

    12.9.1. Less Aggressive passwd.

    The next code block implements the less aggressive passwd command. @@ -7554,8 +7573,8 @@ that the change was completed.\n";

    -
    -

    12.9.2. Less Aggressive Pass Command

    +
    +

    12.9.2. Less Aggressive Pass Command

    The following code block implements the ./inst pass command, used by @@ -7642,8 +7661,8 @@ users:resetpassword command.

    -
    -

    12.9.3. Installing the Less Aggressive passwd

    +
    +

    12.9.3. Installing the Less Aggressive passwd

    The following Ansible tasks install the less aggressive passwd @@ -7711,8 +7730,8 @@ configuration so that the email to root can be encrypted.

    -
    -

    12.10. The Old Command

    +
    +

    12.10. The Old Command

    The old command disables a member's account (and thus their clients). @@ -7756,8 +7775,8 @@ The old command disables a member's account (and thus their clients

    -
    -

    12.11. The Client Command

    +
    +

    12.11. The Client Command

    The client command registers the public key of a client wishing to @@ -8021,8 +8040,8 @@ AllowedIPs = $campus_wg_net_cidr\n";

    -
    -

    12.12. Institute Command Help

    +
    +

    12.12. Institute Command Help

    This should be the last block tangled into the inst script. It @@ -8038,8 +8057,8 @@ above.

    -
    -

    13. Testing

    +
    +

    13. Testing

    The example files in this document, ansible.cfg and hosts as well @@ -8058,7 +8077,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 @@ -8074,8 +8093,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: @@ -8144,14 +8163,14 @@ in 192.168.15.0/24, on the NAT network public.

    -
    -

    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. Preparation of The Hardware installed additional software +drives. Preparation of The Hardware installed additional software packages and keys while the machines had Internet access. They were then moved to the new campus network where Ansible completed the configuration without Internet access. @@ -8169,8 +8188,8 @@ shutting each VM down, executing a VBoxManage command line or two, and restarting.

    -
    -

    13.2.1. The Test Wireguard™ Keys

    +
    +

    13.2.1. The Test Wireguard™ Keys

    All of the private keys used in the example/test configuration are @@ -8235,8 +8254,8 @@ collected (and registered with the ./inst client command).

    -
    -

    13.2.2. Ansible Test Authorization

    +
    +

    13.2.2. Ansible Test Authorization

    Part of each machine's preparation is to authorize password-less SSH @@ -8247,7 +8266,7 @@ provided here tagged with test-auth and used via noweb reference

    -test-auth
    ( cd
+test-auth
    ( cd
   umask 077
   if [ ! -d .ssh ]; then mkdir .ssh; fi
   ( echo -n "ssh-rsa"
@@ -8267,8 +8286,8 @@ provided here tagged with test-auth and used via noweb reference
    -
    -

    13.2.3. A Test Machine

    +
    +

    13.2.3. A Test Machine

    The following shell function contains most of the VBoxManage @@ -8400,8 +8419,8 @@ The administrator logs in here, with username sysadm and password

    -
    -

    13.2.4. The Test Front Machine

    +
    +

    13.2.4. The Test Front Machine

    The front machine is created with 512MiB of RAM, 4GiB of disk, and @@ -8424,12 +8443,11 @@ copied and executed thusly: 

     notebook$ scp private/test-front-prep USER@SERVER:
-notebook$ scp -r Secret/ssh_front/ USER@SERVER:
+notebook$ scp -r private/front_ssh/ USER@SERVER:
 
     sysadm@front$ scp USER@SERVER:test-front-prep ./
-sysadm@front$ scp -r USER@SERVER:ssh_front/ ./
 sysadm@front$ ./test-front-prep
    @@ -8519,19 +8537,16 @@ EOF

    -Ansible expects front to use the SSH host keys in -Secret/ssh_front/, so it is prepared with these keys in advance. -(If Ansible installed them, front would change identities while -Ansible was configuring it. Ansible would lose subsequent access -until the administrator's ~/.ssh/known_hosts was updated!) +Ansible expects private/front_ed25519_key.pub to be the SSH host key +in use on front, so it is prepared with a set of test keys in +advance. Doing so now avoids front changing identities while +Ansible is configuring it (if Ansible were to install the test +identities).

    private/test-front-prep
    
-( cd ssh_front/etc/ssh/
-  chmod 600 ssh_host_*
-  chmod 644 ssh_host_*.pub
-  sudo cp -b ssh_host_* /etc/ssh/ )
+( cd front_ssh/; sudo cp -b ssh_host_* /etc/ssh/ )
    @@ -8544,7 +8559,7 @@ down and moved to the simulated cloud (from the default NAT network). The following VBoxManage commands effect the move, connecting the primary NIC to public and a second NIC to the host-only network vboxnet2 (making it directly accessible to the administrator's -notebook as described in The Test Networks). +notebook as described in The Test Networks).

    @@ -8558,8 +8573,8 @@ VBoxManage modifyvm front --nic2 hostonly --hostonlyadapter2 vboxnet2

    -
    -

    13.2.5. The Test Gate Machine

    +
    +

    13.2.5. The Test Gate Machine

    The gate machine is created with the same amount of RAM and disk as @@ -8573,7 +8588,7 @@ not changed, gate can be created with one command.

    -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 copies the following script to the machine and executes it.

    @@ -8729,8 +8744,8 @@ values of the MAC address variables in this table.

    -
    -

    13.2.6. The Test Core Machine

    +
    +

    13.2.6. The Test Core Machine

    The core machine is created with 1GiB of RAM and 6GiB of disk. @@ -8744,7 +8759,7 @@ created with following command.

    -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 copies the following script to the machine and executes it.

    @@ -8852,8 +8867,8 @@ VBoxManage modifyvm core --nic1 hostonly --hostonlyadapter1 vboxnet0
    -
    -

    13.3. Configure Test Machines

    +
    +

    13.3. Configure Test Machines

    At this point the three test machines core, gate, and front are @@ -8888,8 +8903,8 @@ less than a restart will get systemd-udevd to rename the isp<

    -
    -

    13.4. Test Basics

    +
    +

    13.4. Test Basics

    At this point the test institute is just core, gate and front, @@ -8951,12 +8966,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 Install Nextcloud. Once +installed on core as described in Install Nextcloud. Once /Nextcloud/ is created, ./inst config core will validate or update its configuration files.

    @@ -8978,8 +8993,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 @@ -8999,8 +9014,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, @@ -9028,7 +9043,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 @@ -9042,8 +9057,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 @@ -9085,8 +9100,8 @@ sudo systemctl enable wg-quick@campus

    -
    -

    13.9. Test Campus WireGuard™ Subnet

    +
    +

    13.9. Test Campus WireGuard™ Subnet

    A few basic tests are then performed in a terminal. @@ -9103,8 +9118,8 @@ host www

    -
    -

    13.10. Test Web Pages

    +
    +

    13.10. Test Web Pages

    Next, the administrator copies Backup/WWW/ (included in the @@ -9158,8 +9173,8 @@ the edit observed immediately, and its correction within 15 minutes.

    -
    -

    13.11. Test Nextcloud

    +
    +

    13.11. Test Nextcloud

    Using the browser on the simulated member notebook, the Nextcloud @@ -9236,8 +9251,8 @@ the calendar.

    -
    -

    13.12. Test Email

    +
    +

    13.12. Test Email

    With Evolution running on the member notebook dick, one second email @@ -9265,8 +9280,8 @@ Outgoing email is also tested. A message to

    -
    -

    13.13. Test Public VPN

    +
    +

    13.13. Test Public VPN

    At this point, dick can move abroad, from the campus Wi-Fi @@ -9327,8 +9342,8 @@ calendar events.

    -
    -

    13.14. Test Pass Command

    +
    +

    13.14. Test Pass Command

    To test the ./inst pass command, the administrator logs in to core @@ -9380,8 +9395,8 @@ Finally, the administrator verifies that dick can login on co

    -
    -

    13.15. Test Old Command

    +
    +

    13.15. Test Old Command

    One more institute command is left to exercise. The administrator @@ -9401,16 +9416,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 @@ -9436,16 +9451,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 @@ -9454,8 +9469,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/ @@ -9465,8 +9480,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 @@ -9490,8 +9505,8 @@ could be used.

    -
    -

    15. Appendix: The Bootstrap

    +
    +

    15. Appendix: The Bootstrap

    Creating the private network from whole cloth (machines with recent @@ -9511,11 +9526,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 @@ -9523,8 +9538,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 @@ -9568,8 +9583,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 @@ -9622,7 +9637,7 @@ routes on Front and Gate, making the simulation less… similar.

    Author: Matt Birkholz

    -

    Created: 2025-11-23 Sun 15:25

    +

    Created: 2025-12-30 Tue 20:28

    Validate