running fresh Debian systems with select additional packages, on their
final networks, with a privileged account named ~sysadm~ that
authorizes password-less access from the administrator's notebook,
-ready to be configured by Ansible.
+ready to be configured by Ansible. However the administrator's
+notebook may not recognize the test VMs or, worse yet, remember
+different public keys for them (from previous test machines). For
+this reason, the administrator executes the following commands before
+the initial ~./inst config~.
+
+: ssh sysadm@192.168.56.1 date
+: ssh sysadm@192.168.56.2 date
+: ssh sysadm@192.168.58.3 date
+: ./inst config
-To configure the test machines, the ~./inst config~ command is
-executed. Note that this first run should exercise all of the
-handlers, /and/ that subsequent runs probably /do not/.
+Note that this initial run should exercise all of the handlers, /and/
+that subsequent runs probably /do not/.
Presumably the ~./inst config~ command completed successfully, but
before testing begins, ~gate~ is restarted. Basic networking tests
will fail unless the interfaces on ~gate~ are renamed, and nothing
-less than a restart will get ~systemd-udevd~ to apply the installed
-=.link= files.
-
-# Does this work???
-# udevadm control --reload
-# udevadm trigger -s net -c add -a address=08:00:27:f3:16:79
-# udevadm trigger -s net -c add -a address=08:00:27:4a:de:d2
-# udevadm trigger -s net -c add -a address=08:00:27:3d:42:e5
+less than a restart will get ~systemd-udevd~ to rename the ~isp~ and
+~wifi~ interfaces.
** Test Basics
require several more).
#+BEGIN_SRC
-sudo apt install wireguard nextcloud-desktop evolution
+sudo apt install systemd-resolved \
+ wireguard nextcloud-desktop evolution
#+END_SRC
** Test Client Command
client wishing to connect to the institute's VPNs. In this test, new
member Dick wants to connect his notebook, ~dick~, to the institute
VPNs. First he generates a pair of WireGuard™ keys by running the
-following commands on Dick's notebook.
+following commands on his notebook.
#+BEGIN_SRC sh
-( umask 077; wg genkey >private)
-wg pubkey <private >public
+( umask 077; wg genkey \
+ | sudo tee /etc/wireguard/private-key ) | wg pubkey
#+END_SRC
-The administrator uses the key in =public= to run the following
-command, generating =campus.conf= and =public.conf= files.
+Dick then sends the resulting public key to the administrator, who
+runs the following command.
#+BEGIN_SRC sh
./inst client debian dick dick \
4qd4xdRztZBKhFrX9jI/b4fnMzpKQ5qhg691hwYSsX8=
#+END_SRC
-** Test Campus WireGuard™ Subnet
-
-The =campus.conf= WireGuard™ configuration file (generated in [[*Test Client Command][Test
-Client Command]]) is transferred to ~dick~, which is at the Wi-Fi access
-point's IP address, host 2 on the wild Ethernet.
+The command generates =campus.conf= and =public.conf= configuration
+files, which the administrator sends, openly (e.g. in email) to Dick.
+Dick then installs the configuration files in =/etc/wireguard/= and
+creates the ~campus~ interface.
#+BEGIN_SRC sh
-scp *.conf sysadm@192.168.57.2:
+sudo cp {campus,public}.conf /etc/wireguard/
+sudo wg-quick up campus
+sudo systemctl enable wg-quick@campus
#+END_SRC
-Dick then pastes his notebook's private key into the template
-=campus.conf= file and installs the result in
-=/etc/wireguard/wg0.conf=, doing the same to complete =public.conf=
-and install it in =/etc/wireguard/wg1.conf=.
-
-To connect to the campus VPN, the following command is run.
-
-#+BEGIN_SRC sh
-systemctl start wg-quick@wg0
-#+END_SRC
+** Test Campus WireGuard™ Subnet
A few basic tests are then performed in a terminal.
appropriately.
#+BEGIN_SRC sh
-sudo chown -R sysadm.staff /WWW/campus
-sudo chown -R monkey.staff /WWW/live /WWW/test
+sudo chown -R monkey:staff /WWW/campus /WWW/live /WWW/test
sudo chmod 02775 /WWW/*
sudo chmod 664 /WWW/*/index.html
+sudo -u monkey /usr/local/sbin/webupdate
#+END_SRC
then uses Firefox on ~dick~ to fetch the following URLs. They should
- ~http://live.small.private/~
- ~http://test/~
- ~http://test.small.private/~
- - ~http://small.example.org/~
-The last URL should re-direct to ~https://small.example.org/~, which
-uses a certificate (self-)signed by an unknown authority. Firefox
-will warn but allow the luser to continue.
+The first will probably be flagged as unverifiable, signed by an
+unknown issuer, etc. Otherwise, each should be accessible, displaying
+a short description of the website that was being simulated.
-** Test Web Update
+The simulated public web site at ~http://192.168.15.4/~ is also
+tested. It should redirect to ~https://small.example.org/~, which
+does not exist. However, the web site at ~https://192.168.15.4/~
+(with ~httpS~) should exist and produce a legible page (after the
+usual warnings).
-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=
-on ~front~).
-
-Hack =/home/www/index.html= on ~front~ and observe the result at
-~https://small.example.org/~. Wait 15 minutes for the correction.
+Next the administrator modifies =/WWW/live/index.html= on ~core~ and
+waits 15 minutes for the edit to appear in the web page at
+~https://192.168.15.4/~ (and in the file =/home/www/index.html= on
+~front~). The same is done to =/home/www/index.html= on ~front~ and
+the edit observed immediately, and its correction within 15 minutes.
** Test Nextcloud
-Nextcloud is typically installed and configured /after/ the first
-Ansible run, when ~core~ has Internet access via ~gate~. Until the
-installation directory =/Nextcloud/nextcloud/= appears, the Ansible
-code skips parts of the Nextcloud configuration. The same
-installation (or restoration) process used on Core is used on ~core~
-to create =/Nextcloud/=. The process starts with [[*Create =/Nextcloud/=][Create
-=/Nextcloud/=]], involves [[*Restore Nextcloud][Restore Nextcloud]] or [[*Install Nextcloud][Install Nextcloud]],
-and runs ~./inst config core~ again [[*Afterwards]]. 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.
+Using the browser on the simulated member notebook, the Nextcloud
+installation on ~core~ can be completed. The following steps are
+performed on ~dick~'s desktop.
-- Use a web browser to get ~http://core/nextcloud/~. It should be a
- warning about accessing Nextcloud by an untrusted name.
+- Get ~http://core/nextcloud/~. The attempt produces a warning about
+ using Nextcloud via an untrusted name.
-- Get ~https://core.small.private/nextcloud/~. It should be a
- login web page.
+- Get ~https://core.small.private/nextcloud/~. Receive a login page.
- Login as ~sysadm~ with password ~fubar~.
- Examine the security & setup warnings in the Settings >
Administration > Overview web page. A few minor warnings are
- expected (besides the admonishment about using ~http~ rather than
- ~https~).
+ expected.
- Download and enable Calendar and Contacts in the Apps > Featured web
page.
- Logout and login as ~dick~ with Dick's initial password (noted
above).
-- Use the Nextcloud app to sync =~/nextCloud/= with the cloud. In the
- Nextcloud app's Connection Wizard (the initial dialog), choose to
- "Log in to your Nextcloud" with the URL
- ~https://core.small.private/nextcloud~. The web browser should pop
- up with a new tab: "Connect to your account". Press "Log in" and
- "Grant access". The Nextcloud Connection Wizard then prompts for
- sync parameters. The defaults are fine. Presumably the Local
- Folder is =/home/sysadm/Nextcloud/=.
+- Use the Nextcloud app to sync =~/Nextcloud/= with the cloud. In the
+ Nextcloud Desktop app's Connection Wizard (the initial dialog),
+ login with the URL ~https://core.small.private/nextcloud~. The web
+ browser should pop up with a new tab: "Connect to your account".
+ Press "Log in" and "Grant access". The Nextcloud Connection Wizard
+ then prompts for sync parameters. The defaults are fine.
+ Presumably the Local Folder is =/home/sysadm/Nextcloud/=.
-- Drop a file in =~/Nextcloud/=, use the app to force a sync, and find
- the file in the Files web page.
+- Drop a file in =~/Nextcloud/=, then find it in the Nextcloud Files
+ web page.
- Create a Mail account in Evolution. This step does not involve
Nextcloud, but placates Evolution's Welcome Wizard, and follows in
At this point, ~dick~ can move abroad, from the campus Wi-Fi
(host-only network ~vboxnet1~) to the broader Internet (the NAT
network ~public~). The following command makes the change. The
-machine does not need to be shut down.
+machine does not need to be shut down if the GUI is used to change its
+NIC.
#+BEGIN_SRC s
VBoxManage modifyvm dick --nic1 natnetwork --natnetwork1 public
host www
#+END_SRC
-And these web pages are fetched with a browser.
+And, again, these web pages are fetched with a browser.
- - http://www/
- - http://www.small.private/
- - http://live/
- - http://live.small.private/
- - http://test/
- - http://test.small.private/
- - http://small.example.org/
+ - ~http://www/~
+ - ~http://www.small.private/~
+ - ~http://live/~
+ - ~http://live.small.private/~
+ - ~http://test/~
+ - ~http://test.small.private/~
+ - ~http://192.168.15.4/~
+ - ~https://192.168.15.4/~
+ - ~http://core.small.private/nextcloud/~
The Nextcloud web pages too should still be refresh-able, editable,
and Evolution should still be able to edit messages, contacts and
To test the ~./inst pass~ command, the administrator logs in to ~core~
as ~dick~ and runs ~passwd~. A random password is entered, more
-obscure than ~fubar~ (else Nextcloud will reject it!). The
-administrator then finds the password change request message in the
-most recent file in =/home/sysadm/Maildir/new/= and pipes it to the
-~./inst pass~ command. The administrator might do that by copying the
-message to a more conveniently named temporary file on ~core~,
-e.g. =~/msg=, copying that to the current directory on the notebook,
-and feeding it to ~./inst pass~ on its standard input.
+obscure than ~fubar~ (else Nextcloud will reject it!).
+
+The administrator then finds the password change request message in
+the most recent file in =/home/sysadm/Maildir/new/= and pipes it to
+the ~./inst pass~ command. The administrator might do that by copying
+the message to a more conveniently named temporary file on ~core~,
+e.g. =~/msg=, copying that to the current directory on the
+administrator's notebook, and feeding it to ~./inst pass~ on standard
+input.
On ~core~, logged in as ~sysadm~:
#+BEGIN_SRC sh
+sudo -u dick passwd
( cd ~/Maildir/new/
cp `ls -1t | head -1` ~/msg )
grep Subject: ~/msg
projects / Institute.git / commitdiff