Jason,
> From what I can see, none of what you've written describes what's lacking in
> a potential command that would tail the wireguard log and print it to
> standard out, perpetually. At least I couldn't figure it out from a close
> read. As I wrote before, you could then pipe this into event log or into any
> place else. You spoke more about why snapshotted logs are problematic, and
> I'm inclined to agree with you for a few reasons (though not the one you
> mentioned). But what I'm suggesting is a tail mode, that keeps spitting out
> new logs as they arrive. Are pipes problematic? Is there no ingestor that
> reads data from stdin that would be convenient to you? Where does the tail
> approach fall short? Does the message-based approach of event log clash with
> the line-based approach of wireguard's unix-like logs? I would like to fully
> understand what about this approach fails to meet your design criteria.
I think tail mode could work. It would be easier than parsing the binary file.
I can write a script that runs wireguard.exe continuously with the tail option
and collect stdout. Maybe it can be made to work universally with minimal
effort, so that it works problem-free on whatever WireGuard hosts I push it to.
If you write it, I'll try it.
> One thing we could pretty easily do is add a "WireGuardEventLogger"
service, {un,}installable with:
>> wireguard /installeventlogger
>> wireguard /uninstalleventlogger
>which would then scoop up the binary log as it grows and spit it out to event
>logger, in real time. This wouldn't be too hard to do.
>However, I would really like to first understand precisely what the
>shortcomings would be in a simpler tail subcommand. That seems a lot more
>versatile and simpler to implement too.
The service approach is interesting, too. It would be simpler to ingest.
In terms of shortcomings, consider the typical organization that wants to
collect logs with (for example) Splunk.
They want to collect Exchange Mail logs. The Splunk administrator writes a
monitor stanza for each Event Log and each directory with text logs, pushes it
to the servers, and log events begin pouring in to indexers.
They want to collect Postfix logs. Same process, different OS.
They want to collect appliance syslogs. Set up forwarding to a Splunk listener
and done.
They want to collect WireGuard logs. Well, now that's different, but only on
Windows. Here, you need to write a script that runs software external to
Splunk, and runs it continuously, and collects the output. Will every host have
WireGuard installed? Forever? The script will have to check that the product is
installed or else continuously generate errors. Is wireguard.exe in the PATH?
For the user that Splunk runs under? Does that user have permissions to the
WireGuard program directory? Should the script check the registry for the
executable's location if it's not in the path? Can we run that script on
endpoints without checking each team's security policy regarding in-house
software running executables outside of its scope?
I don't know what all the shortcomings of a tail subcommand are, but these
questions come to mind even before any development is started. So is tail more
versatile and simpler? For whom?
That said, I think it would be a good start.
Frank Wayne
-----Original Message-----
From: Jason A. Donenfeld <[email protected]>
Sent: Thursday, 14 October, 2021 15:03
To: Frank Wayne <[email protected]>
Cc: WireGuard mailing list <[email protected]>
Subject: Re: Windows Log Output to Event Viewer or Text File
Hi Frank,
From what I can see, none of what you've written describes what's lacking in a
potential command that would tail the wireguard log and print it to standard
out, perpetually. At least I couldn't figure it out from a close read. As I
wrote before, you could then pipe this into event log or into any place else.
You spoke more about why snapshotted logs are problematic, and I'm inclined to
agree with you for a few reasons (though not the one you mentioned). But what
I'm suggesting is a tail mode, that keeps spitting out new logs as they arrive.
Are pipes problematic? Is there no ingestor that reads data from stdin that
would be convenient to you? Where does the tail approach fall short? Does the
message-based approach of event log clash with the line-based approach of
wireguard's unix-like logs? I would like to fully understand what about this
approach fails to meet your design criteria.
One thing we could pretty easily do is add a "WireGuardEventLogger"
service, {un,}installable with:
> wireguard /installeventlogger
> wireguard /uninstalleventlogger
which would then scoop up the binary log as it grows and spit it out to event
logger, in real time. This wouldn't be too hard to do.
However, I would really like to first understand precisely what the
shortcomings would be in a simpler tail subcommand. That seems a lot more
versatile and simpler to implement too.
Thanks,
Jason
