TinCanTech wrote
Why do you want this ?
Not OP, but I would have loved this. My use case: I'm admin of a site with a lot of users with varying versions of clients. One thing I do is try to keep an eye out for older versions and nag people occasionally to keep up.
If you're running a 2.4.6 client, great, nothing to do. If you're running 2.4.4, are you on tunnelblick on mac and thus I should nag you, or are you on Ubuntu17 and I should leave you alone? If you're 2.3.x and mac maybe I nag you. If you're 2.3 and linux you're probably Ubuntu 14 and I leave you alone.
When things are split out like the logs are now, this becomes a nontrivial scripting effort because, while those are all vertically grouped to the eyeball, they're different lines that need something to ingest the file, key off sourceip:sourceport, etc. If they were on one line... cat log|grep 'IV_VER=2\.3\.' | grep -v IV_PLAT=linux
I can see why it's done the way it is.. it very much resembles the format of seeing environmental variable output. But since it's buried in logs, it's just a wad of text for human eyeballs, while difficult for sysadmins to do anything with. But, it's only logged to syslog, from what I can tell, so, it's the only game in town.
Now, what'd be awesome (and, I think, a decent compromise vs. changing the longstanding logging format), is if I could connect to the management port and say 'peer-info cn [n]'. At that point, even if you have everything on multiple lines, I don't care, because I then know can associate all those lines of output to the specific user I asked for. And you can copy the prior art of 'status [n]' to have that 'n' cause variable output formats of the peer info (multiple lines, CSV like status, keyvalue CSV like OP asked for), for parsing.
yes yes, inb4 "sounds great, go write it."
