From fca64b12defac256c824af647dfc0200d608aec6 Mon Sep 17 00:00:00 2001 From: Matt Birkholz Date: Mon, 26 Feb 2024 19:43:02 -0700 Subject: [PATCH] Update README.html. --- README.html | 1175 ++++++++++++++++++++++++++------------------------- 1 file changed, 611 insertions(+), 564 deletions(-) diff --git a/README.html b/README.html index 98664c6..765c7fc 100644 --- a/README.html +++ b/README.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - + A Small Institute @@ -48,7 +48,7 @@ connects to Front making the institute email, cloud, etc. available to members off campus.

-
+
                 =                                                   
               _|||_                                                 
         =-The-Institute-=                                           
@@ -1030,7 +1030,7 @@ example result follows the code.
 

 
 
-

+

 

 => 10.62.17.0/24
 

@@ -1230,7 +1230,7 @@ file, copied it to the droplet, and installed it as the
 
 notebook$ cat ~/.ssh/id_rsa.pub Secret/ssh_admin/id_rsa.pub \
 notebook_     > admin_keys
-notebook$ rsync admin_keys sysadm@159.65.75.60:
+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
@@ -1247,6 +1247,31 @@ 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.
+

+
+
+notebook$ scp Secret/ssh_front/etc/ssh/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
+

+
+
+

+The last command removes the old host key from the administrator's
+known_hosts file.  The next SSH connection should ask to confirm the
+new host identity.
+

+
 

 The administrator then tested the password-less ssh login as well as
 the privilege escalation command.
@@ -1345,8 +1370,10 @@ modem and installed them as shown below.
 

 
 
-$ sudo apt install openssh-server rsync isc-dhcp-server netplan.io \
-_                  bind9 fetchmail openvpn apache2
+$ sudo apt install netplan.io systemd-resolved unattended-upgrades \
+_                  ntp isc-dhcp-server bind9 apache2 openvpn \
+_                  postfix dovecot-imapd fetchmail expect rsync \
+_                  gnupg openssh-server
 

 
 
@@ -1357,12 +1384,23 @@ final configuration "in position" (on a frontier).
 

 
 
-$ sudo apt install mariadb-server php php-{bcmath,curl,gd,gmp,json}\
-_                  php-{mysql,mbstring,intl,imagick,xml,zip} \
+$ sudo apt install mariadb-server php php-{apcu,bcmath,curl,gd,gmp}\
+_                  php-{json,mysql,mbstring,intl,imagick,xml,zip} \
 _                  libapache2-mod-php
 

 
 
+

+Similarly, the NAGIOS configuration requires a handful of packages
+that were pre-loaded via cable modem (to test a frontier deployment).
+

+
+
+$ sudo apt install nagios4 monitoring-plugins-basic lm-sensors \
+_                  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
@@ -1373,7 +1411,7 @@ key found in Secret/ssh_admin/ (created b
 
 notebook$ cat ~/.ssh/id_rsa.pub Secret/ssh_admin/id_rsa.pub \
 notebook_     > admin_keys
-notebook$ rsync admin_keys sysadm@core.lan:
+notebook$ scp admin_keys sysadm@core.lan:
 The authenticity of host 'core.lan' can't be established.
 ....
 Are you sure you want to continue connecting (...)? yes
@@ -1445,7 +1483,7 @@ USB-Ethernet adapter, or a wireless adapter connected to a
 campground Wi-Fi access point, etc.
 
 
-
+
 =============== | ==================================================
                 |                                           Premises
           (Campus ISP)                                              
@@ -1468,7 +1506,7 @@ This avoids the need for a second Wi-Fi access point and leads to the
 following topology.
 

 
-
+
 =============== | ==================================================
                 |                                           Premises
            (House ISP)                                              
@@ -1541,7 +1579,9 @@ cable modem and installed them as shown below.
 

 
 
-$ sudo apt install openssh-server isc-dhcp-server netplan.io
+$ sudo apt install netplan.io systemd-resolved unattended-upgrades \
+_                  ufw isc-dhcp-server postfix openvpn \
+_                  openssh-server
 

 
 
@@ -1555,7 +1595,7 @@ key found in Secret/ssh_admin/ (created b
 
 notebook$ cat ~/.ssh/id_rsa.pub Secret/ssh_admin/id_rsa.pub \
 notebook_     > admin_keys
-notebook$ rsync admin_keys sysadm@gate.lan:
+notebook$ scp admin_keys sysadm@gate.lan:
 The authenticity of host 'gate.lan' can't be established.
 ....
 Are you sure you want to continue connecting (...)? yes
@@ -1611,10 +1651,73 @@ At this point Gate was ready for provisioning with Ansible.
 

 

 
-

-
6. The Front 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

+

+

+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
+Particulars).  The code block below is the first to tangle into
+roles/all/tasks/main.yml.
+

+
+

+roles/all/tasks/main.yml
---
+- name: Include public variables.
+  include_vars: ../public/vars.yml
+  tags: accounts
+

+

+

+

+

+
6.2. 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.
+

+
+

+roles_t/all/tasks/main.yml
+- name: Trust the institute CA.
+  become: yes
+  copy:
+    src: ../Secret/CA/pki/ca.crt
+    dest: /usr/local/share/ca-certificates/{{ domain_name }}.crt
+    mode: u=r,g=r,o=r
+    owner: root
+    group: root
+  notify: Update CAs.
+

+

+
+

+roles_t/all/handlers/main.yml
+- name: Update CAs.
+  become: yes
+  command: update-ca-certificates
+

+

+

+

+

+

+
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
@@ -1640,20 +1743,13 @@ uses the institute's CA and server certificates, and expects client
 certificates signed by the institute CA.
 

 

-

-
6.1. Include Particulars

-

-

-The front role's tasks contain references to several common
-institute particulars, variables in the public and private vars.yml
-files and the institute membership roll in private/members.yml.  The
-first front role tasks are to include these files (described in The
-Particulars and Account Management).
-

-
+

+
7.1. Include Particulars

+

 

-The code block below is the first to tangle into
-roles/front/tasks/main.yml.
+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.
 

 
 

@@ -1673,9 +1769,9 @@ The code block below is the first to tangle into
 

 

 

-

-
6.2. Configure Hostname

-

+

+
7.2. Configure Hostname

+

 

 This task ensures that Front's /etc/hostname and /etc/mailname are
 correct.  The correct /etc/mailname is essential to proper email
@@ -1705,8 +1801,8 @@ delivery.
 

 

 

-
6.3. Enable Systemd Resolved 

-

+
7.3. Enable Systemd Resolved 

+

 

 The systemd-networkd and systemd-resolved service units are not
 enabled by default in Debian, but are the default in Ubuntu, and
@@ -1798,9 +1894,9 @@ separate code block named enable-resolved.
 

 

-

-
6.4. Add Administrator to System Groups

-

+

+
7.4. Add Administrator to System Groups

+

 

 The administrator often needs to read (directories of) log files owned
 by groups root and adm.  Adding the administrator's account to
@@ -1820,8 +1916,8 @@ these groups speeds up debugging.
 

 

 
-

-
6.6. Configure Monkey

-

+

+
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
@@ -1900,8 +1996,8 @@ key on Core.
 

 

 

-
6.7. Install Rsync

-

+
7.7. Install Rsync

+

 

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

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

 

 

-

-
6.8. Install Unattended Upgrades

-

+

+
7.8. Install Unattended Upgrades

+

 

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

@@ -1931,9 +2027,9 @@ The institute prefers to install security updates as soon as possible.
 

 

 

-

-
6.9. Configure User Accounts

-

+
 

-

-
6.10. Trust Institute Certificate Authority

-

-

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

-
-

-roles_t/front/tasks/main.yml
-- name: Trust the institute CA.
-  become: yes
-  copy:
-    src: ../Secret/CA/pki/ca.crt
-    dest: /usr/local/share/ca-certificates/{{ domain_name }}.crt
-    mode: u=r,g=r,o=r
-    owner: root
-    group: root
-  notify: Update CAs.
-

-

-
-

-roles_t/front/handlers/main.yml
-- name: Update CAs.
-  become: yes
-  command: update-ca-certificates
-

-

-

-

-

-
6.11. Install Server Certificate

-

+

+
7.10. Install Server Certificate

+

 

 The servers on Front use the same certificate (and key) to
 authenticate themselves to institute clients.  They share the
@@ -2040,8 +2103,8 @@ readable by root.
 

 

 

-
6.12. Configure Postfix on Front

-

+
7.11. 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
@@ -2232,8 +2295,8 @@ start and enable the service.
 

 

 

-
6.13. Configure Public Email Aliases

-

+
7.12. 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
@@ -2273,9 +2336,9 @@ created by a more specialized role.
 

 

 

-

-
6.14. Configure Dovecot IMAPd

-

+

+
7.13. 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
@@ -2345,8 +2408,8 @@ and enables it to start at every reboot.
 

 

 

-
6.15. Configure Apache2 

-

+
7.14. 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
@@ -2738,9 +2801,9 @@ the users' ~/Public/HTML/ directories.
 

 

 

-

-
6.16. Configure OpenVPN

-

+

+
7.15. Configure OpenVPN

+

 

 Front uses OpenVPN to provide the institute's public VPN service.  The
 configuration is straightforward with one complication.  OpenVPN needs
@@ -2937,8 +3000,8 @@ configure the OpenVPN server on Front.
 

 

 

-
6.17. Configure Kamailio

-

+
7.16. 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
@@ -3053,8 +3116,8 @@ Finally, Kamailio can be configured and started.
 

 

 

-
7. 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
@@ -3063,9 +3126,9 @@ Debian install and remote access to a privileged, administrator's
 account.  (For details, see The Core Machine.)
 

 

-

-
7.1. Include Particulars

-

+

+
8.1. Include Particulars

+

 

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

 

 

-

-
7.2. Configure Hostname

-

+

+
8.2. Configure Hostname

+

 

 This task ensures that Core's /etc/hostname and /etc/mailname are
 correct.  Core accepts email addressed to the institute's public or
@@ -3120,9 +3183,9 @@ proper email delivery.
 

 

 

-

-
7.3. Enable Systemd Resolved

-

+

+
8.3. Enable Systemd Resolved

+

 

 Core starts the systemd-networkd and systemd-resolved service
 units on boot.  See Enable Systemd Resolved.
@@ -3165,9 +3228,9 @@ units on boot.  See Enable Systemd Resolved.
 

 

 

-

-
7.4. Configure Systemd Resolved

-

+

+
8.4. Configure Systemd Resolved

+

 

 Core runs the campus name server, so Resolved is configured to use it
 (or dns.google), to include the institute's domain in its search
@@ -3210,8 +3273,8 @@ list, and to disable its cache and stub listener.
 

 

 

-
7.5. Configure Netplan

-

+
8.5. Configure Netplan

+

 

 Core's network interface is statically configured using Netplan and an
 /etc/netplan/60-core.yaml file.  That file provides Core's address
@@ -3222,6 +3285,18 @@ created here.  It is created by OpenVPN when Core connects to Front's
 VPN.
 

 
+

+Core's Netplan needs the name of its main (only) Ethernet interface,
+an example of which is given here.  (A clever way to extract that name
+from ansible_facts would be appreciated.  The ansible_default_ipv4
+fact was an empty hash at first boot on a simulated campus Ethernet.)
+

+
+

+private/vars.yml
core_ethernet:              enp0s3
+

+

+
 

 roles_t/core/tasks/main.yml
 - name: Install netplan.
@@ -3235,7 +3310,7 @@ VPN.
       network:
         renderer: networkd
         ethernets:
-          {{ ansible_default_ipv4.interface }}:
+          {{ core_ethernet }}:
             dhcp4: false
             addresses: [ {{ core_addr_cidr }} ]
             nameservers:
@@ -3258,8 +3333,8 @@ VPN.
 

 

 

-
7.6. Configure DHCP For the Private Ethernet

-

+
8.6. Configure DHCP For the Private Ethernet

+

 

 Core speaks DHCP (Dynamic Host Configuration Protocol) using the
 Internet Software Consortium's DHCP server.  The server assigns unique
@@ -3324,7 +3399,7 @@ with the real private/core-dhcpd.confline: INTERFACESv4="{{ ansible_default_ipv4.interface }}"
+    line: INTERFACESv4="{{ core_ethernet }}"
     regexp: ^INTERFACESv4=
   notify: Restart DHCP server.
 
@@ -3356,8 +3431,8 @@ with the real private/core-dhcpd.conf
 

 
-

-
7.8. Add Administrator to System Groups

-

+

+
8.8. Add Administrator to System Groups

+

 

 The administrator often needs to read (directories of) log files owned
 by groups root and adm.  Adding the administrator's account to
@@ -3654,9 +3729,9 @@ these groups speeds up debugging.
 

 

 

-

-
7.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
@@ -3722,9 +3797,9 @@ described in *Configure Apache2).
 

 

 

-

-
7.10. Install unattended-upgrades

-

+

+
8.10. Install Unattended Upgrades

+

 

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

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

 

 

-
7.11. Install Expect

-

+
8.11. Install Expect

+

 

 The expect program is used by The Institute Commands to interact
 with Nextcloud on the command line.
@@ -3755,9 +3830,9 @@ with Nextcloud on the command line.
 

 

 

-

-
7.12. Configure User Accounts

-

+

+
8.12. Configure User Accounts

+

 

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

 

 

-

-
7.13. Trust Institute Certificate Authority

-

-

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

-
-

-roles_t/core/tasks/main.yml
-- name: Trust the institute CA.
-  become: yes
-  copy:
-    src: ../Secret/CA/pki/ca.crt
-    dest: /usr/local/share/ca-certificates/{{ domain_name }}.crt
-    mode: u=r,g=r,o=r
-    owner: root
-    group: root
-  notify: Update CAs.
-

-

-
-

-roles_t/core/handlers/main.yml
-- name: Update CAs.
-  become: yes
-  command: update-ca-certificates
-

-

-

-

-

-
7.14. Install Server Certificate

-

+

+
8.13. 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
@@ -3862,8 +3904,8 @@ themselves to institute clients.  They share the /etc/server.crt and
 

 

 

-
7.15. Install NTP

-

+
8.14. Install NTP

+

 

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

 

 

-
7.16. Configure Postfix on Core

-

+
8.15. Configure Postfix on Core

+

 

 Core uses Postfix to provide SMTP service to the campus.  The default
 Debian configuration (for an "Internet Site") is nearly sufficient.
@@ -4048,8 +4090,8 @@ enable the service.  Whenever /etc/postfix/transport is changed, the
 

 

 

-
7.17. Configure Private Email Aliases

-

+
8.16. Configure Private Email Aliases

+

 

 The institute's Core needs to deliver email addressed to institute
 aliases including those advertised on the campus web site, in VPN
@@ -4085,9 +4127,9 @@ installed by more specialized roles.
 

 

 

-

-
7.18. Configure Dovecot IMAPd

-

+

+
8.17. Configure Dovecot IMAPd

+

 

 Core uses Dovecot's IMAPd to store and serve member emails.  As on
 Front, Core's Dovecot configuration is largely the Debian default with
@@ -4152,8 +4194,8 @@ and enables it to start at every reboot.
 

 

 

-
7.19. Configure Fetchmail

-

+
8.18. Configure Fetchmail

+

 

 Core runs a fetchmail for each member of the institute.  Individual
 fetchmail jobs can run with the --idle option and thus can
@@ -4330,8 +4372,8 @@ Otherwise the following task might be appropriate.
 

 

 

-
7.20. Configure Apache2 

-

+
8.19. Configure Apache2 

+

 

 This is the small institute's campus web server.  It hosts several web
 sites as described in The Web Services.
@@ -4538,6 +4580,17 @@ interfere with mapping URLs to the correct virtual host.
     name: "{{ item }}"
   loop: [ userdir, cgi ]
   notify: Restart Apache2.
+  when: ansible_distribution != 'Debian'
+        or 12 > ansible_distribution_major_version|int
+
+- name: Enable Apache2 modules (Debian 12).
+  become: yes
+  apache2_module:
+    name: "{{ item }}"
+  loop: [ userdir, cgid ]
+  notify: Restart Apache2.
+  when: ansible_distribution == 'Debian'
+        and 11 < ansible_distribution_major_version|int
@@ -4670,8 +4723,8 @@ The a2ensite command enables them.
-

7.21. Configure Website Updates

-
+

8.20. Configure Website Updates

+

Monkey on Core runs /usr/local/sbin/webupdate every 15 minutes via a cron job. The example script mirrors /WWW/live/ on Core to @@ -4721,8 +4774,8 @@ provided here.

-

7.22. Configure OpenVPN Connection to Front

-
+

8.21. Configure OpenVPN Connection to Front

+

Core connects to Front's public VPN to provide members abroad with a route to the campus networks. As described in the configuration of @@ -4843,8 +4896,8 @@ for Core.

-

7.23. Configure NAGIOS

-
+

8.22. Configure NAGIOS

+

Core runs a nagios4 server to monitor "services" on institute hosts. The following tasks install the necessary packages and configure the @@ -4925,8 +4978,8 @@ Core and Campus (and thus Gate) machines.

-

7.23.1. Configure NAGIOS Monitors for Core

-
+

8.22.1. Configure NAGIOS Monitors for Core

+

The first block in nagios.cfg specifies monitors for services on Core. The monitors are simple, local plugins, and the block is very @@ -5001,8 +5054,8 @@ used here may specify plugin arguments.

-

7.23.2. Custom NAGIOS Monitor inst_sensors

-
+

8.22.2. Custom NAGIOS Monitor inst_sensors

+

The check_sensors plugin is included in the package monitoring-plugins-basic, but it does not report any readings. The @@ -5113,8 +5166,8 @@ Core.

-

7.23.3. Configure NAGIOS Monitors for Remote Hosts

-
+

8.22.3. Configure NAGIOS Monitors for Remote Hosts

+

The following sections contain code blocks specifying monitors for services on other campus hosts. The NAGIOS server on Core will @@ -5135,8 +5188,8 @@ on each campus host by the campus role's Configure NRPE

-

7.23.4. Configure NAGIOS Monitors for Gate

-
+

8.22.4. Configure NAGIOS Monitors for Gate

+

Define the monitored host, gate. Monitor its response to network pings. @@ -5267,8 +5320,8 @@ Monitor inst_sensors on Gate.

-

7.24. Configure Backups

-
+

8.23. Configure Backups

+

The following task installs the backup script from private/. An example script is provided in here. @@ -5287,8 +5340,8 @@ example script is provided in here.

-

7.25. Configure Nextcloud

-
+

8.24. Configure Nextcloud

+

Core runs Nextcloud to provide a private institute cloud, as described in The Cloud Service. Installing, restoring (from backup), and @@ -5299,8 +5352,8 @@ afterwards.

-

7.25.1. Prepare Core For Nextcloud

-
+

8.24.1. Prepare Core For Nextcloud

+

The Ansible code contained herein prepares Core to run Nextcloud by installing required software packages, configuring the web server, and @@ -5493,7 +5546,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 7.25.5 subsection below, before occ +given in the 8.24.5 subsection below, before occ maintenance:install can run.

@@ -5532,8 +5585,8 @@ its document root.
-

7.25.2. Configure PHP

-
+

8.24.2. Configure PHP

+

The following tasks set a number of PHP parameters for better performance, as recommended by Nextcloud. @@ -5547,6 +5600,17 @@ performance, as recommended by Nextcloud. path: /etc/php/7.4/apache2/php.ini regexp: memory_limit *= line: memory_limit = 512M + when: ansible_distribution != 'Debian' + or 12 > ansible_distribution_major_version|int + +- name: Set PHP memory_limit for Nextcloud (Debian 12). + become: yes + lineinfile: + path: /etc/php/8.2/apache2/php.ini + regexp: memory_limit *= + line: memory_limit = 512M + when: ansible_distribution == 'Debian' + and 11 < ansible_distribution_major_version|int - name: Include PHP parameters for Nextcloud. become: yes @@ -5576,8 +5640,8 @@ performance, as recommended by Nextcloud.

-

7.25.3. Create /Nextcloud/

-
+

8.24.3. Create /Nextcloud/

+

The Ansible tasks up to this point have completed Core's LAMP stack and made Core ready to run Nextcloud, but they have not installed @@ -5635,8 +5699,8 @@ sudo mount /Nextcloud

-

7.25.4. Restore Nextcloud

-
+

8.24.4. Restore Nextcloud

+

Restoring Nextcloud in the newly created /Nextcloud/ presumably starts with plugging in the portable backup drive and unlocking it so @@ -5687,8 +5751,8 @@ Overview web page.

-

7.25.5. Install Nextcloud

-
+

8.24.5. Install Nextcloud

+

Installing Nextcloud in the newly created /Nextcloud/ starts with downloading and verifying a recent release tarball. The following @@ -5759,8 +5823,8 @@ Administration > Overview page.

-

7.25.6. Afterwards

-
+

8.24.6. Afterwards

+

Whether Nextcloud was restored or installed, there are a few things Ansible can do to bolster reliability and security (aka privacy). @@ -5942,8 +6006,8 @@ run before the next backup.

-

8. The Gate Role

-
+

9. The Gate Role

+

The gate role configures the services expected at the campus gate: a VPN into the campus network via a campus Wi-Fi access point, and @@ -5970,9 +6034,9 @@ applied first, by which Gate gets a campus machine's DNS and Postfix configurations, etc.

-
-

8.1. Include Particulars

-
+
+

9.1. Include Particulars

+

The following should be familiar boilerplate by now.

@@ -5993,8 +6057,8 @@ The following should be familiar boilerplate by now.
-

8.2. Configure Netplan

-
+

9.2. Configure Netplan

+

Gate's network interfaces are configured using Netplan and two files. /etc/netplan/60-gate.yaml describes the static interfaces, to the @@ -6009,9 +6073,9 @@ example code here.

-private/vars.yml
gate_lan_mac:               ff:ff:ff:ff:ff:ff
-gate_wifi_mac:              ff:ff:ff:ff:ff:ff
-gate_isp_mac:               ff:ff:ff:ff:ff:ff
+private/vars.yml
gate_lan_mac:               08:00:27:f3:16:79
+gate_isp_mac:               08:00:27:3d:42:e5
+gate_wifi_mac:              08:00:27:4a:de:d2
@@ -6090,8 +6154,8 @@ campus ISP without interference from Ansible.
-

8.3. UFW Rules

-
+

9.3. UFW Rules

+

Gate uses the Uncomplicated FireWall (UFW) to install its packet filters at boot-time. The institute does not use a firewall except to @@ -6174,8 +6238,8 @@ the wifi device to the lan device, just the ovpn

-

8.4. Install UFW

-
+

9.4. Install UFW

+

The following tasks install the Uncomplicated Firewall (UFW), set its policy in /etc/default/ufw, and install the above rules in @@ -6241,8 +6305,8 @@ sudo ufw enable

-

8.5. Configure DHCP For The Gate-WiFi Ethernet

-
+

9.5. Configure DHCP For The Gate-WiFi Ethernet

+

To accommodate commodity Wi-Fi access points without re-configuring them, the institute attempts to look like an up-link, an ISP, e.g. a @@ -6345,9 +6409,9 @@ the daemon listens only on the Gate-WiFi network interface.

-
-

8.6. Install Server Certificate

-
+
+

9.6. Install Server Certificate

+

The (OpenVPN) server on Gate uses an institute certificate (and key) to authenticate itself to its clients. It uses the /etc/server.crt @@ -6373,9 +6437,9 @@ and Front) do.

-
-

8.7. Configure OpenVPN

-
+
+

9.7. Configure OpenVPN

+

Gate uses OpenVPN to provide the institute's campus VPN service. Its clients are not configured to route all of their traffic through @@ -6520,8 +6584,8 @@ configure the OpenVPN server on Gate.

-

9. The Campus Role

-
+

10. The Campus Role

+

The campus role configures generic campus server machines: network NAS, DVRs, wireless sensors, etc. These are simple Debian machines @@ -6537,9 +6601,9 @@ Wireless campus devices can get a key to the campus VPN from the configured manually.

-
-

9.1. Include Particulars

-
+
+

10.1. Include Particulars

+

The following should be familiar boilerplate by now.

@@ -6554,9 +6618,9 @@ The following should be familiar boilerplate by now.
-
-

9.2. Configure Hostname

-
+
+

10.2. Configure Hostname

+

Clients should be using the expected host name.

@@ -6582,9 +6646,9 @@ Clients should be using the expected host name.
-
-

9.3. Enable Systemd Resolved

-
+
+

10.3. Enable Systemd Resolved

+

Campus machines start the systemd-networkd and systemd-resolved service units on boot. See Enable Systemd Resolved. @@ -6627,9 +6691,9 @@ service units on boot. See Enable Systemd Resolved.

-
-

9.4. Configure Systemd Resolved

-
+
+

10.4. Configure Systemd Resolved

+

Campus machines use the campus name server on Core (or dns.google), and include the institute's private domain in their search lists. @@ -6669,8 +6733,8 @@ and include the institute's private domain in their search lists.

-

9.5. Configure Systemd Timesyncd

-
+

10.5. Configure Systemd Timesyncd

+

The institute uses a common time reference throughout the campus. This is essential to campus security, improving the accuracy of log @@ -6699,9 +6763,9 @@ and file timestamps.

-
-

9.6. Add Administrator to System Groups

-
+
+

10.6. Add Administrator to System Groups

+

The administrator often needs to read (directories of) log files owned by groups root and adm. Adding the administrator's account to @@ -6720,42 +6784,9 @@ these groups speeds up debugging.

-
-

9.7. Trust Institute Certificate Authority

-
-

-Campus hosts should recognize the institute's Certificate Authority as -trustworthy, so its certificate is added to the host's set of trusted -CAs. (For more information about how the small institute manages its -keys, certificates and passwords, see Keys.) -

- -
-roles_t/campus/tasks/main.yml
-- name: Trust the institute CA.
-  become: yes
-  copy:
-    src: ../Secret/CA/pki/ca.crt
-    dest: /usr/local/share/ca-certificates/{{ domain_name }}.crt
-    mode: u=r,g=r,o=r
-    owner: root
-    group: root
-  notify: Update CAs.
-
-
- -
-roles_t/campus/handlers/main.yml
-- name: Update CAs.
-  become: yes
-  command: update-ca-certificates
-
-
-
-
-
-

9.8. Install Unattended Upgrades

-
+
+

10.7. Install Unattended Upgrades

+

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

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

9.9. Configure Postfix on Campus

-
+

10.8. Configure Postfix on Campus

+

The Postfix settings used by the campus include message size, queue times, and the relayhost Core. The default Debian configuration @@ -6835,8 +6866,8 @@ tasks below.

-

9.10. Hard-wire Important IP Addresses

-
+

10.9. Hard-wire Important IP Addresses

+

For the edification of programs consulting the /etc/hosts file, the institute's domain name and public IP address are added. The Debian @@ -6864,8 +6895,8 @@ custom of translating the host name into 127.0.1.1 is also followed

-

9.11. Configure NRPE

-
+

10.10. 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 @@ -6924,8 +6955,8 @@ Role.

-

10. The Ansible Configuration

-
+

11. The Ansible Configuration

+

The small institute uses Ansible to maintain the configuration of its servers. The administrator keeps an Ansible inventory in hosts, and @@ -6947,8 +6978,8 @@ separate revision history.

-

10.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 @@ -6979,8 +7010,8 @@ described in Keys) and thus sets this parameter to

-

10.2. hosts

-
+

11.2. hosts

+

The Ansible inventory file hosts describes all of the institute's machines starting with the main servers Front, Core and Gate. It @@ -7057,8 +7088,8 @@ the Secret/vault-password file.

-

10.3. playbooks/site.yml

-
+

11.3. playbooks/site.yml

+

The example playbooks/site.yml playbook (below) applies the appropriate institutional role(s) to the hosts and groups defined in @@ -7067,6 +7098,10 @@ the example inventory: hosts.

playbooks/site.yml
---
+- name: Configure All
+  hosts: all
+  roles: [ all ]
+
 - name: Configure Front
   hosts: front
   roles: [ front ]
@@ -7087,8 +7122,8 @@ the example inventory: hosts.
-

10.4. Secret/vault-password

-
+

11.4. Secret/vault-password

+

As already mentioned, the small institute keeps its Ansible vault password, a "master secret", on the encrypted partition mounted at @@ -7105,8 +7140,8 @@ example password matches the example encryptions above.

-

10.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 @@ -7189,8 +7224,8 @@ super-project's directory.

-

10.6. Maintaining A Working Ansible Configuration

-
+

11.6. Maintaining A Working Ansible Configuration

+

The Ansible roles currently tangle into the roles_t/ directory to ensure that debugged Ansible code in roles/ is not clobbered by code @@ -7209,8 +7244,8 @@ their way back to the code block in this document.

-

11. The Institute Commands

-
+

12. The Institute Commands

+

The institute's administrator uses a convenience script to reliably execute standard procedures. The script is run with the command name @@ -7220,8 +7255,8 @@ to get their defaults from ./ansible.cfg.

-

11.1. Sub-command Blocks

-
+

12.1. Sub-command Blocks

+

The code blocks in this chapter tangle into the inst script. Each block examines the script's command line arguments to determine @@ -7245,8 +7280,8 @@ The first code block is the header of the ./inst script.

-

11.2. Sanity Check

-
+

12.2. Sanity Check

+

The next code block does not implement a sub-command; it implements part of all ./inst sub-commands. It performs a "sanity check" on @@ -7306,8 +7341,8 @@ permissions. It probes past the Secret/ mount poin

-

11.3. Importing Ansible Variables

-
+

12.3. Importing Ansible Variables

+

To ensure that Ansible and ./inst are sympatico vis-a-vi certain variable values (esp. private values like network addresses), a @@ -7356,8 +7391,8 @@ The playbook that updates private/vars.pl:

-

11.4. The CA Command

-
+

12.4. The CA Command

+

The next code block implements the CA sub-command, which creates a new CA (certificate authority) in Secret/CA/ as well as SSH and PGP @@ -7465,8 +7500,8 @@ config.

-

11.5. The Config Command

-
+

12.5. The Config Command

+

The next code block implements the config sub-command, which provisions network services by running the site.yml playbook @@ -7517,8 +7552,8 @@ Example command lines:

-

11.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 @@ -7721,8 +7756,8 @@ each record.

-

11.7. The New Command

-
+

12.7. The New Command

+

The next code block implements the new sub-command. It adds a new member to the institute's membership roll. It runs an Ansible @@ -7826,8 +7861,8 @@ initial, generated password.

-

11.8. The Pass Command

-
+

12.8. The Pass Command

+

The institute's passwd command on Core securely emails root with a member's desired password (hashed). The command may update the @@ -7841,8 +7876,8 @@ message is sent to member@core.

-

11.8.1. Less Aggressive passwd.

-
+

12.8.1. Less Aggressive passwd.

+

The next code block implements the less aggressive passwd command. It is less aggressive because it just emails root. It does not @@ -7938,8 +7973,8 @@ print "

-

11.8.2. Less Aggressive Pass Command

-
+

12.8.2. Less Aggressive Pass Command

+

The following code block implements the ./inst pass command, used by the administrator to update private/members.yml before running @@ -8036,8 +8071,8 @@ users:resetpassword command using expect(1).

-

11.8.3. Installing the Less Aggressive passwd

-
+

12.8.3. Installing the Less Aggressive passwd

+

The following Ansible tasks install the less aggressive passwd script in /usr/local/bin/passwd on Core, and a sudo policy file @@ -8105,8 +8140,8 @@ configuration so that the email to root can be encrypted.

-

11.9. The Old Command

-
+

12.9. The Old Command

+

The old command disables a member's accounts and clients.

@@ -8151,8 +8186,8 @@ The old command disables a member's accounts and clients.
-

11.10. The Client Command

-
+

12.10. The Client Command

+

The client command creates an OpenVPN configuration (.ovpn) file authorizing wireless devices to connect to the institute's VPNs. The @@ -8323,8 +8358,8 @@ up-restart

-

11.11. Institute Command Help

-
+

12.11. Institute Command Help

+

This should be the last block tangled into the inst script. It catches any command lines that were not handled by a sub-command @@ -8340,31 +8375,31 @@ above.

-

12. Testing

-
+

13. Testing

+

-The example files in this document, ansible.cfg and hosts as -well as those in public/ and private/, along with the -matching EasyRSA certificate authority and GnuPG key-ring in -Secret/ (included in the distribution), can be used to configure -three VirtualBox VMs simulating Core, Gate and Front in a test network -simulating a campus Ethernet, campus ISP, and commercial cloud. With -the test network up and running, a simulated member's notebook can be -created, and alternately attached to the simulated campus Wi-Fi or the -simulated Internet (as though abroad). The administrator's notebook -in this simulation is the VirtualBox host. +The example files in this document, ansible.cfg and hosts as well +as those in public/ and private/, along with the matching EasyRSA +certificate authority and GnuPG key-ring in Secret/ (included in the +distribution), can be used to configure three VirtualBox VMs +simulating Core, Gate and Front in test networks simulating a campus +Ethernet, Wi-Fi, ISP, and a commercial cloud. With the test networks +up and running, a simulated member's notebook can be created and +alternately attached to the simulated campus Wi-Fi or the Internet (as +though abroad). The administrator's notebook in this simulation is +the VirtualBox host.

The next two sections list the steps taken to create the simulated -Core, Gate and Front, and connect them to a simulated campus Ethernet, -campus ISP, and commercial cloud. 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 process, simulating an administrator -adding and removing member accounts and devices, a member's desktop -sending and receiving email, etc. +Core, Gate and Front machines, and connect them to their networks. +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 +process, simulating an administrator adding and removing member +accounts and devices, a member's desktop sending and receiving email, +etc.

@@ -8375,8 +8410,8 @@ site at https://www.

-

12.1. The Test Networks

-
+

13.1. The Test Networks

+

The networks used in the test:

@@ -8392,29 +8427,19 @@ private Ethernet switch. It has no services, no DHCP, just the host machine at 192.168.56.10 pretending to be the administrator's notebook. -
vboxnet1

-Another Host-only network, simulating the tiny +

vboxnet1
Another Host-only network, simulating the tiny Ethernet between Gate and the campus Wi-Fi access point. It has no -services, no DHCP, just the host at 192.168.57.2. It might one -day have a simulated access point at that address. Currently it is -just an interface for gate's DHCP server to listen on. -

- -

-In this simulation the IP address for front is not a public -address but a private address on the NAT network premises. Thus -front is not accessible to the administrator's notebook (the -host). To work around this restriction, front gets a second -network interface connected to the vboxnet1 network and used only -for ssh access from the host.5 -

+services, no DHCP, just the host at 192.168.57.2, simulating the +NATed Wi-Fi network.

-As in The Hardware, all machines start with their primary Ethernet -adapters attached to the NAT Network premises so that they can -download additional packages. Later, core and gate are moved to -the simulated private Ethernet vboxnet0. +In this simulation the IP address for front is not a public address +but a private address on the NAT network premises. Thus front is +not accessible to the administrator's notebook (the host). To work +around this restriction, front gets a second network interface +connected to the vboxnet1 network and used only for ssh access from +the host.5

@@ -8428,37 +8453,50 @@ following VBoxManage commands. --enable --dhcp on --ipv6 off VBoxManage natnetwork start --netname premises VBoxManage hostonlyif create # vboxnet0 -VBoxManage hostonlyif ipconfig vboxnet0 --ip 192.168.56.10 \ - --dhcp off --ipv6 off +VBoxManage hostonlyif ipconfig vboxnet0 --ip=192.168.56.10 +VBoxManage dhcpserver modify --interface=vboxnet0 --disable VBoxManage hostonlyif create # vboxnet1 -VBoxManage hostonlyif ipconfig vboxnet1 --ip 192.168.57.2 \ - --dhcp off --ipv6 off +VBoxManage hostonlyif ipconfig vboxnet1 --ip=192.168.57.2

-Note that actual ISPs and clouds will provide Gate and Front with -public network addresses but in this simulation "they" provide -addresses in the private 192.168.15.0/24 network. +Note that the first host-only network, vboxnet0, gets DHCP service +by default, but that will interfere with the service being tested on +core, so it must be explicitly disabled. Only the NAT network +premises should have a DHCP server enabled. +

+ +

+Note also that actual ISPs and clouds will provide Gate and Front with +public network addresses. In this simulation "they" provide addresses +on the private 192.168.15.0/24 network.

-

12.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-11.3.0-amd64-netinst.iso) on the NAT network -premises. As in The Hardware preparation process being simulated, a -few additional software packages are installed and remote access is -authorized before the machines are moved to their final networks, -prepared for Ansible. +(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 +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.) +

+ +

+Once the administrator's notebook is authorized to access the +privileged accounts on the virtual machines, they are prepared for +configuration by Ansible.

-

12.2.1. A Test Machine

-
+

13.2.1. A Test Machine

+

The following shell function contains most of the VBoxManage commands needed to create the test machines. The name of the machine @@ -8485,47 +8523,42 @@ taken from the ISO shell variable. VBoxManage storageattach $NAME --storagectl "IDE Controller" \ --port 0 --device 0 --type dvddrive --medium $ISO VBoxManage modifyvm $NAME --boot1 dvd --boot2 disk - VBoxManage unattended install $NAME --iso=$ISO \ - --locale en_US --country US \ - --hostname $NAME.small.private \ - --user=sysadm --password=fubar \ - --full-user-name=System\ Administrator }

After this shell function creates a VM, its network interface is -typically attached to the NAT network premises, simulating the -Internet connected network where actual hardware will be prepared. +attached to the default NAT network, simulating the Internet connected +network where actual hardware is prepared.

Here are the commands needed to create the test machine front with -512MiB of RAM and 4GiB of disk and the Debian 11.3.0 release in its -CDROM drive, to put front on the Internet connected NAT network -premises, and to boot front into the Debian installer. +512MiB of RAM and 4GiB of disk and the Debian 12.5.0 release in its +CDROM drive. 

NAME=front
 RAM=512
 DISK=4096
-ISO=~/Downloads/debian-11.3.0-amd64-netinst.iso
+ISO=~/Downloads/debian-12.5.0-amd64-netinst.iso
 create_vm
-VBoxManage modifyvm $NAME --nic1 natnetwork --natnetwork1 premises
-VBoxManage startvm $NAME --type headless

-The machine's console should soon show the installer's first prompt: -to choose a system language. The appropriate responses to the -installer's prompts are given in the list below. +Soon after starting, the machine console should show the installer's +first prompt: to choose a system language. Installation on the small +machines, front and gate, may put the installation into "low +memory mode", in which case the installation is textual, the system +language is English, and the first prompt is for location. The +appropriate responses to the prompts are given in the list below.

    -
  • Select a language +
  • Select a language (unless in low memory mode!)
    • Language: English - English
    • @@ -8586,101 +8619,76 @@ installer's prompts are given in the list below.

-After the reboot (first boot into the installed OS) the machine's -console should produce a login: prompt. The administrator logs in -here, with username sysadm and password fubar, before continuing -with the specific machine's preparation (below). +After the reboot, the machine's console should produce a login: +prompt. The administrator logs in here, with username sysadm and +password fubar, before continuing with the specific machine's +preparation (below).

-

12.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 -Debian 11.3.0 (recently downloaded) in its CDROM drive. The exact +Debian 12.5.0 (recently downloaded) in its CDROM drive. The exact command lines were given in the previous section.

-After Debian is installed (as detailed in A Test Machine) and the -machine rebooted, the administrator logs in and installs several -additional software packages. +After Debian is installed (as detailed above) front is shut down and +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).

-
sudo apt install netplan.io expect unattended-upgrades postfix \
-                 dovecot-imapd apache2 openvpn
+
VBoxManage modifyvm front --nic1 natnetwork --natnetwork1 premises
+VBoxManage modifyvm front --nic2 hostonly --hostonlyadapter2 vboxnet1

-Note that the Postfix installation may prompt for a couple settings. -The defaults, listed below, are fine. -

- -
    -
  • General type of mail configuration: Internet Site
    • -
  • System mail name: small.example.org
    • -
- -

-To make front accessible to the simulated administrator's notebook, -it gets a second network interface attached to the host-only network -vboxnet1 and is given the local address 192.168.57.3. +After Debian is installed and the machine rebooted, the administrator +logs in and configures the "extra" network interface with a static IP +address using a drop-in configuration file: +/etc/network/interfaces.d/eth1.

-
VBoxManage modifyvm front --nic2 hostonly --hostonlyadapter2 vboxnet1
+eth1
auto enp0s8
+iface enp0s8 inet static
+    address 192.168.57.3/24

-The second network interface is configured with an IP address via the -Netplan configuration file /etc/netplan/01-testing.yaml, which is -created with the following lines. +A sudo ifup enp0s8 command then brings the interface up.

-
-
network:
-  ethernets:
-    enp0s8:
-      dhcp4: false
-      addresses: [ 192.168.57.3/24 ]
-
-
-

-The amended Netplan is applied immediately with the following command, -or the machine is rebooted. -

- -
-
sudo netplan apply
-
-
- -

-Finally, the administrator authorizes remote access by following the -instructions in the final section: Ansible Test Authorization. +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 +Test Authorization.

-

12.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 front. Assuming the RAM, DISK, and ISO shell variables have -not changed, gate can be created with two commands, then connected -to NAT network premesis and booted with two more. +not changed, gate can be created with two commands. 

NAME=gate
 create_vm
-VBoxManage modifyvm gate --nic1 natnetwork --natnetwork1 premises
-VBoxManage startvm gate --type headless
@@ -8691,8 +8699,8 @@ additional software packages.

-
sudo apt install netplan.io ufw unattended-upgrades postfix \
-                 isc-dhcp-server openvpn
+
sudo apt install netplan.io systemd-resolved unattended-upgrades \
+                 ufw isc-dhcp-server postfix openvpn
@@ -8707,29 +8715,26 @@ defaults, listed below, are fine.

-gate can now move to the campus. It is shut down before the +gate can then move to the campus. It is shut down before the following VBoxManage commands are executed. The commands disconnect -the primary Ethernet interface from premises and -connected it to vboxnet0. The isp and wifi interfaces are also +the primary Ethernet interface from premises and connected it to +vboxnet0. They also create two new interfaces, isp and wifi, connected to the simulated ISP and campus wireless access point.

-
VBoxManage modifyvm gate --nic1 hostonly
-VBoxManage modifyvm gate --hostonlyadapter1 vboxnet0
+
VBoxManage modifyvm gate --mac-address1=080027f31679
+VBoxManage modifyvm gate --nic1 hostonly --hostonlyadapter1 vboxnet0
+VBoxManage modifyvm gate --mac-address2=0800273d42e5
 VBoxManage modifyvm gate --nic2 natnetwork --natnetwork2 premises
-VBoxManage modifyvm gate --nic3 hostonly
-VBoxManage modifyvm gate --hostonlyadapter3 vboxnet1
+VBoxManage modifyvm gate --mac-address3=0800274aded2
+VBoxManage modifyvm gate --nic3 hostonly --hostonlyadapter3 vboxnet1

-Before rebooting, the MAC addresses of the three network interfaces -should be compared to the example variable settings in hosts. The -values of the gate_lan_mac, gate_wifi_mac, and gate_isp_mac -variables must agree with the MAC addresses assigned to the virtual -machine's network interfaces. The following table assumes device -names that may vary depending on the hypervisor, version, etc. +The MAC addresses above were specified so they match the example +values of the MAC address variables in this table.

@@ -8777,7 +8782,7 @@ names that may vary depending on the hypervisor, version, etc.

-After gate boots up with its new network connections, the primary +After gate boots up with its new network interfaces, the primary Ethernet interface is temporarily configured with an IP address. (Ansible will install a Netplan soon.)

@@ -8794,8 +8799,8 @@ instructions in the final section: Ansible Test Authorizat
-

12.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. Assuming the ISO shell variable has not changed, core can be @@ -8807,8 +8812,6 @@ created with following commands. RAM=2048 DISK=6144 create_vm -VBoxManage modifyvm core --nic1 natnetwork --natnetwork1 premises -VBoxManage startvm core --type headless

@@ -8819,14 +8822,20 @@ additional software packages.

-
sudo apt install netplan.io unattended-upgrades postfix \
-                 isc-dhcp-server bind9 fetchmail gnupg \
-                 expect dovecot-imapd apache2 openvpn
+
sudo apt install netplan.io systemd-resolved unattended-upgrades \
+                 ntp isc-dhcp-server bind9 apache2 openvpn \
+                 postfix dovecot-imapd fetchmail expect rsync \
+                 gnupg
+sudo apt install mariadb-server php php-{apcu,bcmath,curl,gd,gmp}\
+                 php-{json,mysql,mbstring,intl,imagick,xml,zip} \
+                 libapache2-mod-php
+sudo apt install nagios4 monitoring-plugins-basic lm-sensors \
+                 nagios-nrpe-plugin

-Again, the Postfix installation prompts for a couple settings. The +Again the Postfix installation prompts for a couple settings. The defaults, listed below, are fine.

@@ -8835,6 +8844,13 @@ defaults, listed below, are fine.
  • System mail name: core.small.private
    • +

    +Before shutting down, the name of the primary Ethernet interface +should be compared to the example variable setting in +private/vars.yml. The value assigned to core_ethernet should +match the interface name. +

    +

    core can now move to the campus. It is shut down before the following VBoxManage command is executed. The command connects the @@ -8849,13 +8865,12 @@ Ethernet.

    After core boots up with its new network connection, its primary NIC -is temporarily configured with an IP address and default route (to -gate). (Ansible will install a Netplan soon.) +is temporarily configured with an IP address. (Ansible will install a +Netplan soon.) 

    sudo ip address add 192.168.56.1/24 dev enp0s3
-sudo ip route add default via 192.168.56.2 dev enp0s3
    @@ -8866,19 +8881,20 @@ instructions in the next section: Ansible Test Authorizati
    -

    12.2.5. Ansible Test Authorization

    -
    +

    13.2.5. Ansible Test Authorization

    +

    -Before Ansible can configure the three test machines, they must allow -remote access to their sysadm accounts. The administrator must use -IP addresses to copy the public key to each test machine. +To authorize Ansible's access to the three test machines, they must +allow remote access to their sysadm accounts. In the following +commands, the administrator must use IP addresses to copy the public +key to each test machine. 

    SRC=Secret/ssh_admin/id_rsa.pub
-scp $SRC sysadm@192.168.56.1:admin_key # Core
-scp $SRC sysadm@192.168.56.2:admin_key # Gate
 scp $SRC sysadm@192.168.57.3:admin_key # Front
+scp $SRC sysadm@192.168.56.2:admin_key # Gate
+scp $SRC sysadm@192.168.56.1:admin_key # Core
    @@ -8892,12 +8908,48 @@ each machine). 
    ( cd; umask 077; mkdir .ssh; cp admin_key .ssh/authorized_keys )
    + +

    +The front machine needs a little additional preparation. Ansible +will configure front with the host keys in Secret/. These should +be installed there now so that front does not appear to change +identities while Ansible is configuring. +

    + +

    +First, the host keys are securely copied to front with the following +command. +

    + +
    +
    scp Secret/ssh_front/etc/ssh/ssh_host_* sysadm@192.168.57.3:
+
    + +

    +Then they are installed with these commands. +

    + +
    +
    chmod 600 ssh_host_*
+chmod 644 ssh_host_*.pub
+sudo cp -b ssh_host_* /etc/ssh/
+
    + +

    +Finally, the system administrator removes the old identity of front. +

    + +
    +ssh-keygen -f ~/.ssh/known_hosts -R 192.168.57.3
+
    -
    -

    12.3. The Test Ansible Configuration

    -
    +
    +
    +
    +

    13.3. Configure Test Machines

    +

    At this point the three test machines core, gate, and front are running fresh Debian systems with select additional packages, on their @@ -8905,11 +8957,7 @@ final networks, with a privileged account named sysadm that authorizes password-less access from the administrator's notebook, ready to be configured by Ansible.

    -
    -
    -
    -

    12.4. Configure Test Machines

    -
    +

    To configure the test machines, the ./inst config command is executed and core restarted. Note that this first run should @@ -8919,8 +8967,8 @@ not.

    -

    12.5. Test Basics

    -
    +

    13.4. Test Basics

    +

    At this point the test institute is just core, gate and front, no other campus servers, no members nor their VPN client devices. On @@ -8982,8 +9030,8 @@ instant attention).

    -

    12.6. 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 @@ -9009,8 +9057,8 @@ using the ./inst new command and issuing client VPN keys with the

    -

    12.7. Test New Command

    -
    +

    13.6. Test New Command

    +

    A member must be enrolled so that a member's client machine can be authorized and then test the VPNs, Nextcloud, and the web sites. @@ -9030,8 +9078,8 @@ Take note of Dick's initial password.

    -

    12.8. The Test Member Notebook

    -
    +

    13.7. The Test Member Notebook

    +

    A test member's notebook is created next, much like the servers, except with memory and disk space doubled to 2GiB and 8GiB, and a @@ -9045,9 +9093,8 @@ desktop VPN client and web browser test the OpenVPN configurations on RAM=2048 DISK=8192 create_vm -VBoxManage modifyvm $NAME --nic1 hostonly --hostonlyadapter1 vboxnet1 VBoxManage modifyvm $NAME --macaddress1 080027dc54b5 -VBoxManage startvm $NAME --type headless +VBoxManage modifyvm $NAME --nic1 hostonly --hostonlyadapter1 vboxnet1

    @@ -9075,8 +9122,8 @@ require several more).
    -

    12.9. Test Client Command

    -
    +

    13.8. Test Client Command

    +

    The ./inst client command is used to issue keys for the institute's VPNs. The following command generates two .ovpn (OpenVPN @@ -9092,8 +9139,8 @@ the test VPNs.

    -

    12.10. Test Campus VPN

    -
    +

    13.9. Test Campus VPN

    +

    The campus.ovpn OpenVPN configuration file (generated in Test Client Command) is transferred to dick, which is at the Wi-Fi access @@ -9131,8 +9178,8 @@ host www

    -

    12.11. Test Web Pages

    -
    +

    13.10. Test Web Pages

    +

    Next, the administrator copies Backup/WWW/ (included in the distribution) to /WWW/ on core and sets the file permissions @@ -9171,8 +9218,8 @@ will warn but allow the luser to continue.

    -

    12.12. Test Web Update

    -
    +

    13.11. Test Web Update

    +

    Modify /WWW/live/index.html on core and wait 15 minutes for it to appear as https://small.example.org/ (and in /home/www/index.html @@ -9186,8 +9233,8 @@ Hack /home/www/index.html on front and observe the result at

    -

    12.13. Test Nextcloud

    -
    +

    13.12. Test Nextcloud

    +

    Nextcloud is typically installed and configured after the first Ansible run, when core has Internet access via gate. Until the @@ -9196,7 +9243,7 @@ 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 7.25.6. When the ./inst +and runs ./inst config core again 8.24.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. @@ -9275,8 +9322,8 @@ the calendar.

    -

    12.14. Test Email

    -
    +

    13.13. Test Email

    +

    With Evolution running on the member notebook dick, one second email delivery can be demonstrated. The administrator runs the following @@ -9304,8 +9351,8 @@ Outgoing email is also tested. A message to

    -

    12.15. Test Public VPN

    -
    +

    13.14. Test Public VPN

    +

    At this point, dick can move abroad, from the campus Wi-Fi (host-only network vboxnet1) to the broader Internet (the NAT @@ -9358,8 +9405,8 @@ calendar events.

    -

    12.16. Test Pass Command

    -
    +

    13.15. Test Pass Command

    +

    To test the ./inst pass command, the administrator logs in to core as dick and runs passwd. A random password is entered, more @@ -9406,8 +9453,8 @@ Finally, the administrator verifies that dick can login on co

    -

    12.17. Test Old Command

    -
    +

    13.16. Test Old Command

    +

    One more institute command is left to exercise. The administrator retires dick and his main device dick. @@ -9427,16 +9474,16 @@ should fail.

    -

    13. Future Work

    -
    +

    14. Future Work

    +

    The small institute's network, as currently defined in this doocument, is lacking in a number of respects.

    -

    13.1. Deficiencies

    -
    +

    14.1. Deficiencies

    +

    The current network monitoring is rudimentary. It could use some love, like intrusion detection via Snort or similar. Services on @@ -9502,16 +9549,16 @@ Nextcloud Administration Overview page.

    -

    13.2. More Tests

    -
    +

    14.2. More Tests

    +

    The testing process described in the previous chapter is far from complete. Additional tests are needed.

    -

    13.2.1. Backup

    -
    +

    14.2.1. Backup

    +

    The backup command has not been tested. It needs an encrypted partition with which to sync? And then some way to compare that to @@ -9520,8 +9567,8 @@ partition with which to sync? And then some way to compare that to

    -

    13.2.2. Restore

    -
    +

    14.2.2. Restore

    +

    The restore process has not been tested. It might just copy Backup/ to core:/, but then it probably needs to fix up file ownerships, @@ -9531,8 +9578,8 @@ perhaps permissions too. It could also use an example

    -

    13.2.3. Campus Disconnect

    -
    +

    14.2.3. Campus Disconnect

    +

    Email access (IMAPS) on front is… difficult to test unless core's fetchmails are disconnected, i.e. the whole campus is @@ -9556,8 +9603,8 @@ could be used.

    -

    14. Appendix: The Bootstrap

    -
    +

    15. Appendix: The Bootstrap

    +

    Creating the private network from whole cloth (machines with recent standard distributions installed) is not straightforward. @@ -9577,8 +9624,8 @@ get to the additional packages.

    -

    14.1. The Current Strategy

    -
    +

    15.1. The Current Strategy

    +

    The strategy pursued in The Hardware is two phase: prepare the servers on the Internet where additional packages are accessible, then connect @@ -9589,8 +9636,8 @@ fails), and avoid names until BIND9 is configured.

    -

    14.2. Starting With Gate

    -
    +

    15.2. Starting With Gate

    +

    The strategy of Starting With Gate concentrates on configuring Gate's connection to the campus ISP in hope of allowing all to download @@ -9634,8 +9681,8 @@ ansible-playbook -l core site.yml

    -

    14.3. Pre-provision With Ansible

    -
    +

    15.3. Pre-provision With Ansible

    +

    A refinement of the current strategy might avoid the need to maintain (and test!) lists of "additional" packages. With Core and Gate and @@ -9694,7 +9741,7 @@ routes on Front and Gate, making the simulation less… similar.

    Author: Matt Birkholz

    -

    Created: 2024-01-02 Tue 13:37

    +

    Created: 2024-02-26 Mon 19:42

    Validate

    -- 2.25.1