From 1e4ee6b3bc746d971cba5219d8e2e0d02bd5a36c Mon Sep 17 00:00:00 2001 From: Matt Birkholz Date: Mon, 26 Feb 2024 17:46:15 -0700 Subject: [PATCH] Wordsmithing. Updated installation instructions for Debian 12. --- README.org | 164 ++++++++++++++++++++++++++--------------------------- 1 file changed, 79 insertions(+), 85 deletions(-) diff --git a/README.org b/README.org index d14d042..f66bec6 100644 --- a/README.org +++ b/README.org @@ -963,7 +963,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 @@ -1088,7 +1088,7 @@ key found in [[file:Secret/ssh_admin/][=Secret/ssh_admin/=]] (created by [[*The : 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 @@ -1226,7 +1226,7 @@ key found in [[file:Secret/ssh_admin/][=Secret/ssh_admin/=]] (created by [[*The : 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 @@ -2939,7 +2939,7 @@ described in [[apache2-core][*Configure Apache2]]). mode: "u=rw,g=r,o=" #+END_SRC -** Install ~unattended-upgrades~ +** Install Unattended Upgrades The institute prefers to install security updates as soon as possible. @@ -6754,26 +6754,26 @@ die "usage: $0 [CA|config|new|pass|old|client] ...\n"; * Testing -The example files in this document, [[file:ansible.cfg][=ansible.cfg=]] and [[file:hosts][=hosts=]] as -well as those in [[file:public/][=public/=]] and [[file:private/][=private/=]], along with the -matching EasyRSA certificate authority and GnuPG key-ring in -[[file:Secret/][=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, [[file:ansible.cfg][=ansible.cfg=]] and [[file:hosts][=hosts=]] as well +as those in [[file:public/][=public/=]] and [[file:private/][=private/=]], along with the matching EasyRSA +certificate authority and GnuPG key-ring in [[file:Secret/][=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 Hardware][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 Hardware][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. For more information on the VirtualBox Hypervisor, the User Manual can be found off-line in [[/usr/share/doc/virtualbox/UserManual.pdf]]. An @@ -6796,21 +6796,15 @@ The networks used in the test: - ~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.[fn:5] - -As in [[*The Hardware][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~. + services, no DHCP, just the host at ~192.168.57.2~, simulating the + NATed Wi-Fi network. + +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.[fn:5] The networks described above are created and "started" with the following ~VBoxManage~ commands. @@ -6827,24 +6821,29 @@ VBoxManage hostonlyif create # vboxnet1 VBoxManage hostonlyif ipconfig vboxnet1 --ip=192.168.57.2 #+END_SRC -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. ** 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][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][The Hardware]] preparation process being simulated, a few +additional software packages are installed. Unlike in [[*The Hardware][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. *** A Test Machine @@ -6880,22 +6879,25 @@ 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 +512MiB of RAM and 4GiB of disk and the Debian 12.5.0 release in its CDROM drive. #+BEGIN_SRC sh 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 #+END_SRC -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 - Select your location + Country, territory or area: United States @@ -6932,35 +6934,22 @@ installer's prompts are given in the list below. + Install the GRUB boot loader to your primary drive? Yes + Device for boot loader installation: /dev/sda (ata-VBOX... -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). *** 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][A Test Machine]]) and the -machine rebooted, the administrator logs in and installs several -additional software packages. - -#+BEGIN_SRC sh -sudo apt install netplan.io expect unattended-upgrades postfix \ - dovecot-imapd apache2 openvpn -#+END_SRC - -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 (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][The Test Networks]]). #+BEGIN_SRC sh VBoxManage modifyvm front --nic1 natnetwork --natnetwork1 premises @@ -6981,8 +6970,12 @@ iface enp0s8 inet static A ~sudo ifup enp0s8~ command then brings the interface up. -Finally, the administrator authorizes remote access by following the -instructions in the final section: [[* Ansible Test Authorization][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][Ansible +Test Authorization]]. *** The Test Gate Machine @@ -7013,10 +7006,10 @@ defaults, listed below, are fine. - General type of mail configuration: Internet Site - System mail name: gate.small.private -~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. #+BEGIN_SRC sh @@ -7037,7 +7030,7 @@ values of the MAC address variables in this table. | ~enp0s8~ | ~premises~ | campus ISP | ~gate_isp_mac~ | | ~enp0s9~ | ~vboxnet1~ | campus wireless | ~gate_wifi_mac~ | -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.) @@ -7113,15 +7106,16 @@ instructions in the next section: [[* Ansible Test Authorization][Ansible Test A *** 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. #+BEGIN_SRC sh 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 #+END_SRC Then the key must be installed on each machine with the following -- 2.25.1