On 21.01.24 21:08, Bo Berglund wrote:
Inside the [systemd unit file for] openvpn server [...] this item is defined:
--suppress-timestamps

This means that *all* server instances will get this set even though it is not
in the instance's own conf file!

Now I wonder if there is anything at all one can do on a server instance level
to disable that setting such that the timestamps are returned to the logfiles?

My .02:

.01) The problem isn't restricted to this particular config setting. A while back, when I set up a VPN server with about two handful of OpenVPN server instances running in parallel, I added "daemon MyInstanceName" to the config files so as to have the instances identify themselves in the log - only to find that the parameterless "--daemon" in the back-then unit file overruled that.

.02) OpenVPN prioritizes command line parameters over statements in config files on the theory that someone probably typed them in for *this* particular execution of the openvpn binary - which obviously isn't the case when the command line's given in a systemd unit file. I wonder whether the situation would improve if OpenVPN were to give a *lower* priority config mechanism to the systemd folks. (Single global "template" config file, overridden by the usual per-instance config file?) Note, however, that this *alone* would *not* yet solve this particular problem, as you'd still need config syntax to "undo" the lower-prio setting.

And this has worked just fine, except for the fact that there are no timestamps
inside the logfiles created when it runs.

Another cent on that matter:

.03) You already did notice the *next* problem with forcing $APPLICATION to timestamp its log entries *itself*, instead of letting "the logging system" (journald, (r)syslog(-ng), ...) do that: Yet *another* place to try and get the configuration consistent with the rest of the logs. (Format, timezone, creation vs. arrival time, ...) Not to mention that having $APPLICATION write files directly tends to rather stand in the way of having the logs collected, across servers, in a central (tamper proof) location.

Kind regards,
--
Jochen Bern
Systemingenieur

Binect GmbH

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Reply via email to