: 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
: 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
: 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
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.
* 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
- ~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.
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
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
+ 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
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
- 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
| ~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.)
*** 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
projects / Institute / commitdiff