Windows Log Output to Event Viewer or Text File

[Frank Wayne]

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 <Jason at zx2c4.com> 
Sent: Thursday, 14 October, 2021 15:03
To: Frank Wayne <frank.wayne at northwestern.edu>
Cc: WireGuard mailing list <wireguard at lists.zx2c4.com>
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