You've provided plenty of info now, thanks.

It's irrelevant now (you'll see why below) but FYI you can get the "TurnKey version" from an appliance like this:

turnkey-version

In the case of your server, you'd get this:

turnkey-nextcloud-16.0-buster-amd64

As you'll note, it's the same as the ISO file name, hence why I said it was irrelevant... :)

Anyway, great work on your progress. FWIW I wasn't even aware that waking a computer from sleep without a "Magic Packet" was even possible! So thanks for educating me! :)

Re your questions on the Apache log. It might be nice to think about how we might tidy this up a little, although TBH, it doesn;t really cause too much pain I don't think?! Anyway, AFAIK it's pretty much the default config that ships with Debian, plus the Nextcloud Apache config that we provide that makes it log the way that it does.

At the top of /etc/apache2/sites-available/default-ssl.conf you'll find the following:

<IfModule mod_ssl.c>
	<VirtualHost _default_:443>
		ServerAdmin webmaster@localhost

		DocumentRoot /var/www/html

		# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
		# error, crit, alert, emerg.
		# It is also possible to configure the loglevel for particular
		# modules, e.g.
		#LogLevel info ssl:warn

		ErrorLog ${APACHE_LOG_DIR}/error.log
		CustomLog ${APACHE_LOG_DIR}/access.log combined

Note that the last 2 lines there are defining the default log locations. There's the access.log! :) But if you poke around in the Apache config a bit more, you'll find another CustomLog defined in /etc/apache2/conf-available/other-vhosts-access-log.conf (/etc/apache2/conf-enabled/other-vhosts-access-log.conf is a symlink to this file, as only the files in /etc/apache2/conf-enabled are read - it works similar with sites-available and sites-enabled). Here's other-vhosts-access-log.conf:

# Define an access log for VirtualHosts that don't define their own logfile
CustomLog ${APACHE_LOG_DIR}/other_vhosts_access.log vhost_combined

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

So that sets the other_vhosts_access.log file to be a "catchall" for all vhosts (aka sites) which don't explicitly define a access log location. This overwrites the previously set default access.log file (although the file itself is still created, albeit empty). As we don't define a log location for the CustomLog in the Nextcloud site file (/etc/apache2/sites-available/nextcloud.conf) it falls back to logging in the other_vhosts_access.log file.

Re Webmin, you should find the Webmn logs (or more precisely symlinks to them) in /var/log/webmin. Although please note that Webmin (and Webshell too) are hidden behind stunnel (stunnel is a light weight SSL tunnel that we use as a SSL termination frontend for Webmin). So clients connect to stunnel (on port 12321) which then connects to localhost:10000 (which is what Webmin listens on). So I'm not 100% sure that scanning the Webmin logs will give you the info that you are looking for. By default stunnel has logging disabled, but you could enable it if you wanted which I suspect would likely provide the info you want.

FWIW personally, I reckon that the best way to manage this would be actually monitoring the conenctions, rather than the logs of conenctions. You can get the info about connections using one of the built-in tools. 'ss' works quite well, e.g. something like this (ss -tu) might give you good start?!:

root@lamp ~# ss -tu
Netid              State              Recv-Q               Send-Q                             Local Address:Port                               Peer Address:Port                
tcp                ESTAB              0                    0                                      127.0.0.1:webmin                                127.0.0.1:35892               
tcp                ESTAB              0                    0                                  192.168.1.109:ssh                                192.168.1.56:38902               
tcp                ESTAB              0                    0                                  192.168.1.109:ssh                                192.168.1.56:39616               
tcp                ESTAB              0                    0                                  192.168.1.109:12321                              192.168.1.56:46326               
tcp                ESTAB              0                    0                                      127.0.0.1:35892                                 127.0.0.1:webmin              
tcp                ESTAB              0                    0                                  192.168.1.109:ssh                                192.168.1.56:39776             

Running this on my test (LAMP) server (192.168.1.109) shows that from my laptop (192.168.1.56) I have multiple connections (to my test server). 3x SSH connections and Webmin. If you filter those results so that it only shows remote connections, then you would have something of value IMO.

As we know that the local external IP address (in my case 192.168.1.109) if we collect all the active connections to/from that IP would be a good start. Although 127.0.0.1 is localhost so actually connections between anything and that are internal so have no interest to us here. We can use grep to filter those lines in/out. This should give us just the relevant lines. E.g. something like this (grep's -v switch excludes matches):

ss -tu | grep 192.168.1.109 | grep -v 127.0.0.1

Here it is on hte data from above:

root@lamp ~# ss -tu | grep 192.168.1.109 | grep -v 127.0.0.1                      
tcp                ESTAB              0                    0                                  192.168.1.109:ssh                                192.168.1.56:38902               
tcp                ESTAB              0                    0                                  192.168.1.109:ssh                                192.168.1.56:39616               
tcp                ESTAB              0                    0                                  192.168.1.109:12321                              192.168.1.56:46326               
tcp                ESTAB              0                    0                                  192.168.1.109:ssh                                192.168.1.56:39776  

So if I close all the connections, it should return nothing (FWIW I normally connect to my servers via SSH, as it gives a nie native user experience - so this step required me to log in via the actual VM window):

root@lamp ~# ss -tu | grep 192.168.1.109 | grep -v 127.0.0.1

Yep - it worked! :) The beauty of doing it that way is that even if you install a new service, it will still monitor the activity of the new server without you needing to update your list of log locations to monitor.

FWIW, here's a vaguely similar script similar to what you are using, but this one leverages ss. I also took the liberty of writing it in the style I tend to use and will add some notes at the end.:

#!/bin/bash -e

[[ -z "$DEBUG" ]] || set -x
TIMEOUT=${TIMEOUT:-30} # seconds

connections=$(ss -tu | grep 192.168.1.109 | grep -v 127.0.0.1) || true

if [[ -z "$connections" ]]; then
    sleep $timeout
    exit
fi
exit 1

Notes:

1. It's always good practice to set 'e' for all bash scripts. If you set 'e' (either at the top as I did or via 'set -e') then your script will exit (with exit code 1) if it encounters an error. Otherwise it will ignore the error and just keep executing the next line.
3. Rather than having a commandline debug option, I prefer to use an env var (sometimes I include both). The beauty of using a 'DEBUG' env var is that if you have lots of scripts that you string together, to debug you can just set DEBUG and they all will have debug enabled. Also, I just set 'x' rather than have an explicit debug output. You can add some as well if you wish, but usually the verbose output that 'x' gives is enough (I'll post the output below).
   
4. I set a timeout here, although you could collect it as input if you rather. FWIW, the way that I've done it means that you can also preset this with an env var too if you want. I.e. if $TIMEOUT is set, that will override the built in default (of 30 seconds).
6. This line captures the output of the ss command I gave above. Obviously you'll need to change the external IP of your server. Note that it has the '|| true' (OR True) on the end to ensure that the line never errors. If grep does not find a match it will return a non zero exit code so with no connections and without the '|| true', the script will "exit 1" on this line.
8. Test if $connections is empty.
9. (If no connections) Wait $TIMEOUT seconds.
10. (If no connections) Exit with exit code 99. I used that instead as '1' is the default error code and we've set 'e', Using an alternate non-zero exit code here to signal that there are no connections (i.e. '99') allows you to easily differentiate between the desired result (exit codes of either '0' or '99') vs actual errors (likely '1', but could potentially be others).

I didn't put an 'exit" (or even an 'exit 0') at the end as it's redundant and overly verbose IMO (the script will always exit '0' unless there is an error).

Also, as promised, here is the script run via an SSH session (with just the SSH session connected). Note that I set $DEBUG and a custom TIMEOUT, plus gather the exit code afterwards (as you can see, I called my script 'test'):

root@lamp ~# TIMEOUT=1 DEBUG=y ./test; echo $?
+ TIMEOUT=1
++ ss -tu
++ grep 192.168.1.109
++ grep -v 127.0.0.1
+ connections='tcp     ESTAB   0        200        192.168.1.109:ssh      192.168.1.56:44354   '
+ [[ -z tcp     ESTAB   0        200        192.168.1.109:ssh      192.168.1.56:44354    ]]
0

Now run from the VM window (with no network connections):

root@lamp ~# TIMEOUT=1 DEBUG=y ./test; echo $?
+ TIMEOUT=1
++ ss -tu
++ grep 192.168.1.109
++ grep -v 127.0.0.1
+ connections=
+ [[ -z '' ]]
+ sleep 1
+ exit 99
99

Anyway, I've rambled enough now... :) Hope that's of some value. Good luck with it all and hopefully chat another day...