issues with syslogd include redirecting wg0 output to custom location
Hi,
I'm experimenting with FreeBSD's 14.1's wireguard implementation.
So far i've been quite satisfied with using it locally (over an
unsecured network). I would like to set up a PoC using wg as a VPN
provider (replacing openvpn) next.
Before opening wireguard endpoints up for global connectivity I would
like wireguard logs to be parsed by something like Fail2ban (so I can
have pf ward off baddies). I've managed to get wireguards' logs into
/var/log/messages by issueing:
/sbin/ifconfig wg0 debug
Since they are quite verbose and are polluting /var/log/messages, I'd
like for them to land in /var/ramdisk_log/wireguard.log instead. I've
instructing newsyslog to create the logfile :
[root@system:/]# cat /var/ramdisk_log/wireguard.log
Sep 17 00:27:36 system newsyslog[55203]: logfile first created
[root@system:/]# ls -laht /var/ramdisk_log/wireguard.log
-rw-rw 1 root wheel 66B Sep 17 00:27 /var/ramdisk_log/wireguard.log
[root@system:/]#
and have since attempted to redirect the "wg0" logs to
/var/ramdisk_log/wireguard.log by using these syslog includes:
:msg, contains, ".*wg0: .*"
*.*/var/ramdisk_log/wireguard.log
and
:msg, regex, "wg[0-9]{1,2}\:\ "
*.*/var/ramdisk_log/wireguard.log
Unfortunately, the includes are not redirecting the wg0 logs to my
preferred location (the includes are placed in
/etc/syslog.d/wireguard.conf which is parsed by syslogd) and I'm out of
ideas / logs on how to further troubleshoot why the logstream doesn't
get redirected :(
Im hoping somebody - a little better versed in syslog - could provide me
with some insights / pointers...
Feedback appreciated!
ruben
Re: issues with syslogd include redirecting wg0 output to custom location
On 17/09/2024 13:06, fuxjez wrote:
[..]
and have since attempted to redirect the "wg0" logs to
/var/ramdisk_log/wireguard.log by using these syslog includes:
:msg, contains, ".*wg0: .*"
*.* /var/ramdisk_log/wireguard.log
and
:msg, regex, "wg[0-9]{1,2}\:\ "
*.* /var/ramdisk_log/wireguard.log
Unfortunately, the includes are not redirecting the wg0 logs to my
preferred location (the includes are placed in
/etc/syslog.d/wireguard.conf which is parsed by syslogd) and I'm out of
ideas / logs on how to further troubleshoot why the logstream doesn't
get redirected :(
I never used property based filters in syslog.conf.
Is it possible for you to use just classic style?
For example I use following to have separate log file for messages from
pkg (install / upgrade / delete):
!-pkg,pkg-static
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err
/var/log/messages
!pkg,pkg-static
*.* /var/log/pkg.log
But I don't know how your wg0 debug entries are identified in the
messages log.
Kind regards
Miroslav Lachman
Re: issues with syslogd include redirecting wg0 output to custom location
Hi Miroslav,
Thank you for your suggestion. I got the property based filtering from
the manpage. The entries in /var/log/messages look like these:
wg0: Sending handshake response to peer 1
wg0: Receiving keepalive packet from peer 1
wg0: Sending keepalive packet to peer 1
wg0: Sending keepalive packet to peer 1
wg0: Sending keepalive packet to peer 1
wg0: Receiving handshake initiation from peer 0
wg0: Sending handshake response to peer 0
wg0: Sending keepalive packet to peer 0
wg0: Sending keepalive packet to peer 1
wg0: Receiving handshake initiation from peer 1
wg0: Sending handshake response to peer 1
wg0: Sending keepalive packet to peer 1
replacing:
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err
/var/log/messages
in - /etc/syslog.conf - with:
!-wg0
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err
/var/log/messages
!wg0
*.*
/var/ramdisk_log/wireguard.log
does redirect the logstream perfectly.
Thank you for your suggestion :)
Regards,
ruben
On 9/17/24 14:09, Miroslav Lachman wrote:
On 17/09/2024 13:06, fuxjez wrote:
[..]
and have since attempted to redirect the "wg0" logs to /var/
ramdisk_log/wireguard.log by using these syslog includes:
:msg, contains, ".*wg0: .*"
*.* /var/ramdisk_log/wireguard.log
and
:msg, regex, "wg[0-9]{1,2}\:\ "
*.* /var/ramdisk_log/wireguard.log
Unfortunately, the includes are not redirecting the wg0 logs to my
preferred location (the includes are placed in /etc/syslog.d/
wireguard.conf which is parsed by syslogd) and I'm out of ideas / logs
on how to further troubleshoot why the logstream doesn't get
redirected :(
I never used property based filters in syslog.conf.
Is it possible for you to use just classic style?
For example I use following to have separate log file for messages from
pkg (install / upgrade / delete):
!-pkg,pkg-static
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/
messages
!pkg,pkg-static
*.* /var/log/pkg.log
But I don't know how your wg0 debug entries are identified in the
messages log.
Kind regards
Miroslav Lachman
Re: 13.4 compiles firefox functionally different
On Tue, 17 Sep 2024, Peter wrote: Hi, after upgrading to 13.4-RC2-p1, I recompiled all ports. Today I found my firefox can no longer render a certain webpage; the output is garbled as if the CSS were missing/defective. Here is details and picture: https://forums.freebsd.org/threads/firefox-displays-unintellegible-garbage-only-on-freebsd.94963/post-671994 The firefox version is -esr-115.15.0,1, from 2024Q3 as of a week ago. Investigation showed: * firefox from package as of today (130.something) works well. * firefox-esr from package as of today (128.something) works well. * firefox-esr from ports as of today (128.2.0esr) freshly compiled on 13.4-RC2-p1 also works well (prereqs still from last week) * firefox-esr 115.14.0_1,1 locally compiled a few weeks ago on Rel. 13.3 also works well. So I did verify: I restarted a Rel.13.3-p5, fetched all prereqisite ports from backup (so these were also compiled on 13.3), and then compiled firefox-esr-115.15.0,1, the very same that now renders garbage, using the very same ports tree, with OS running 13.3-p5. And that one now works! So bottomline is: firefox-esr 115.15.0,1 - the one that was in 2024Q3 until about a week ago - works correct when compiled on 13.3 (along with all it's prereq ports), but renders garbage for a certain webpage when compiled on 13.4-RC2 (along with all it's prereq ports). I don't like this, because now the question is: what else might 13.4 compile so that it suddenly functions differently? (I glanced thru PR 277021 - but it doesn't seem to mention anything about webpages displaying broken, or any functional difference) Any idea how this might come to happen, anybody? Probably not related but I'll bring it up anyway; there was issue with firefox/other programs on alpine linux a couple weeks ago where the MESA package's upgrade in combination with using the link time optimization feature under gcc-14.x caused garbled previews and other graphical anomolies on my Firefox and my sway window manager. Not sure which compiler / mesa is used to build firefox on FreeBSD but could be part of the problem I guess or a place to look at the dependencies. It looks like they disabled LTO on the mesa build to fix the issue. That was using mesa-24.2.2. Dan
Re: issues with syslogd include redirecting wg0 output to custom location
Hi,
> On 17 Sep 2024, at 12:06, fuxjez wrote:
>
> Hi,
>
> I'm experimenting with FreeBSD's 14.1's wireguard implementation.
>
> So far i've been quite satisfied with using it locally (over an unsecured
> network). I would like to set up a PoC using wg as a VPN provider (replacing
> openvpn) next.
>
> Before opening wireguard endpoints up for global connectivity I would like
> wireguard logs to be parsed by something like Fail2ban (so I can have pf ward
> off baddies). I've managed to get wireguards' logs into /var/log/messages by
> issueing:
>
> /sbin/ifconfig wg0 debug
>
> Since they are quite verbose and are polluting /var/log/messages, I'd like
> for them to land in /var/ramdisk_log/wireguard.log instead. I've instructing
> newsyslog to create the logfile :
>
> [root@system:/]# cat /var/ramdisk_log/wireguard.log
> Sep 17 00:27:36 system newsyslog[55203]: logfile first created
> [root@system:/]# ls -laht /var/ramdisk_log/wireguard.log
> -rw-rw 1 root wheel 66B Sep 17 00:27 /var/ramdisk_log/wireguard.log
> [root@system:/]#
>
> and have since attempted to redirect the "wg0" logs to
> /var/ramdisk_log/wireguard.log by using these syslog includes:
>
> :msg, contains, ".*wg0: .*"
> *.*/var/ramdisk_log/wireguard.log
I think the value for “contains” has to be a simple string
> and
>
> :msg, regex, "wg[0-9]{1,2}\:\ "
> *.*/var/ramdisk_log/wireguard.log
regex uses a basic RE so it would have to be "wg[0-9]\{1,2\}\:\ “
(ie escape the { } ) ; or if you want an extended (modern) RE:
:msg, ereregex, "wg[0-9]{1,2}\:\ "
>
> Unfortunately, the includes are not redirecting the wg0 logs to my preferred
> location (the includes are placed in /etc/syslog.d/wireguard.conf which is
> parsed by syslogd) and I'm out of ideas / logs on how to further troubleshoot
> why the logstream doesn't get redirected :(
>
> Im hoping somebody - a little better versed in syslog - could provide me with
> some insights / pointers...
>
> Feedback appreciated!
>
> ruben
>
--
Bob Bishop
r...@gid.co.uk
Re: 13.4 compiles firefox functionally different
On Tue, Sep 17, 2024 at 08:35:59AM -0500, Dan Mack wrote: ! On Tue, 17 Sep 2024, Peter wrote: ! ! > Hi, ! > ! > after upgrading to 13.4-RC2-p1, I recompiled all ports. ! > ! > Today I found my firefox can no longer render a certain webpage; ! > the output is garbled as if the CSS were missing/defective. ! > Here is details and picture: ! > https://forums.freebsd.org/threads/firefox-displays-unintellegible-garbage-only-on-freebsd.94963/post-671994 ! > ! > The firefox version is -esr-115.15.0,1, from 2024Q3 as of a ! > week ago. ! > ! > Investigation showed: ! > * firefox from package as of today (130.something) works well. ! > * firefox-esr from package as of today (128.something) works ! > well. ! > * firefox-esr from ports as of today (128.2.0esr) freshly compiled ! > on 13.4-RC2-p1 also works well (prereqs still from last week) ! > * firefox-esr 115.14.0_1,1 locally compiled a few weeks ago on ! > Rel. 13.3 also works well. ! > ! > So I did verify: I restarted a Rel.13.3-p5, fetched all ! > prereqisite ports from backup (so these were also compiled on 13.3), ! > and then compiled firefox-esr-115.15.0,1, the very same that now ! > renders garbage, using the very same ports tree, with OS running ! > 13.3-p5. And that one now works! ! > ! > So bottomline is: ! > firefox-esr 115.15.0,1 - the one that was in 2024Q3 until about a ! > week ago - works correct when compiled on 13.3 (along with all it's ! > prereq ports), but renders garbage for a certain webpage when ! > compiled on 13.4-RC2 (along with all it's prereq ports). ! > ! > I don't like this, because now the question is: what else might 13.4 ! > compile so that it suddenly functions differently? ! > ! > ! > (I glanced thru PR 277021 - but it doesn't seem to mention anything ! > about webpages displaying broken, or any functional difference) ! > ! > Any idea how this might come to happen, anybody? ! ! Probably not related but I'll bring it up anyway; there was issue with ! firefox/other programs on alpine linux a couple weeks ago where the MESA ! package's upgrade in combination with using the link time optimization ! feature under gcc-14.x caused garbled previews and other graphical anomolies ! on my Firefox and my sway window manager. Hi Dan, thanks for Your feedback. This reflects what I happen to say: we're sitting on a huge pile of code, and almost nobody does still understand all the possible interdependencies - we only hunt them when something does visibly malfunction. In my case, this specific webpage brings along some 40k lines of CSS code, and from what I could figure out, firefox downloads them successfully, but then after a few hundred lines they are not applied any further. ! Not sure which compiler / mesa is used to build firefox on FreeBSD but could ! be part of the problem I guess or a place to look at the dependencies. It ! looks like they disabled LTO on the mesa build to fix the issue. That was ! using mesa-24.2.2. Firefox builds rust and llvm-17 from ports as prereq. It could be that these work someway different when built on 13.4. And that is exactly where my belly starts hurting: these compilers are used for other software too.
