From: Matt Birkholz Date: Fri, 21 Nov 2025 00:15:25 +0000 (-0700) Subject: Wordsmithing. Updated the testing instructions for Debian 12. X-Git-Url: https://birchwood-abbey.net/git?a=commitdiff_plain;h=8ee32161ae34fcce1837e275e86f0bfd9f9e4cf1;p=Institute Wordsmithing. Updated the testing instructions for Debian 12. --- diff --git a/README.org b/README.org index e57930f..bf253a3 100644 --- a/README.org +++ b/README.org @@ -7448,23 +7448,25 @@ At this point the three test machines ~core~, ~gate~, and ~front~ are 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 @@ -7575,7 +7577,8 @@ desktop and installs a couple additional software packages (which 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 @@ -7584,41 +7587,33 @@ The ~./inst client~ command is used to register the public key of a 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 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. @@ -7638,10 +7633,10 @@ distribution) to =/WWW/= on ~core~ and sets the file permissions 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 @@ -7654,47 +7649,39 @@ the source file. - ~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. @@ -7702,17 +7689,16 @@ the following tests on ~dick~'s desktop. - 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 @@ -7771,7 +7757,8 @@ Outgoing email is also tested. A message to 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 @@ -7794,15 +7781,17 @@ host core.small.private 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 @@ -7812,17 +7801,20 @@ calendar events. 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