Bug: Audit log entries are written to files with old timestamps

[corbin-phipps]

Describe the bug
The plog loggers are created in the beginning of src/linux/server/Main::main(), which only gets executed one-time when the netremote server is installed on a system. The date of installation is used for the log file path, e.g. 20240730-LogNetRemote-audit.txt. This means that if netremote is used on a future date (e.g. 20240801), then those log entries will still write to 20240730-LogNetRemote-audit.txt.

Steps To Reproduce

1. Install netremote-server.
2. On a future date, perform a Wi-Fi action that causes an entry to be written to the audit log.

Expected behavior
Audit log entries should be written to a log file that has the timestamp of the same date of the log entries themselves.

Actual behavior
Audit log entries are written to the log file that has the timestamp from the installation date.

Example output
cat /var/log/20240724-LogNetRemote-audit.txt
2024-07-24 18:34:18.078 NONE [36787] [main@109] Netremote server starting (log level=info)
2024-07-30 17:25:01.429 INFO [36824] [Microsoft::Net::Wifi::AccessPointControllerLinux::SetOperationalState@159] Operational state of AP wlo1 set to 'disabled'

[abeltrano]

The plog loggers are created in the beginning of src/linux/server/Main::main(), which only gets executed one-time when the netremote server is installed on a system. The date of installation is used for the log file path, e.g. 20240730-LogNetRemote-audit.txt.

As a quick clarification, the loggers are instantiated each time the netremote-server binary is run, and so the date/timestamp will be for that date. This doesn't change the issue described since there can still be a time lag between when the binary was executed and when the test was run.