Am 24.01.2021 um 13:18 schrieb Alejandro Colomar:
> This is useful for using tee to just write to a file,
> at the end of a pipeline,
> without having to redirect to /dev/null
>
> Example:
>
> echo 'foo' | sudo tee -q /etc/foo;
>
> is equivalent to the old (and ugly)
>
> echo 'foo' | sudo tee
Unwind / libunbound goes pretty badly off the rails when an address
family is not available, it still tries to talk to nameservers with an
unreachable address family.
I don't think it's libunbound's place to figure this out. It can't
sensibly do a getifaddrs on every query...
So let's help it out
On Mon, Jan 25, 2021 at 05:08:48PM +0100, Florian Obser wrote:
> We are not getting anything useful for us out of it and it can be
> quite noisy when we are missing IPv4 or IPv6 addresses as pointed out
> by kn@.
> It is still available when logging to stderr when running with -d.
OK kn
> Also
On Mon, Jan 25, 2021 at 07:05:40PM +0100, Florian Obser wrote:
> Unwind / libunbound goes pretty badly off the rails when an address
> family is not available, it still tries to talk to nameservers with an
> unreachable address family.
> I don't think it's libunbound's place to figure this out. It
On 25 January 2021 20:56:36 CET, Klemens Nanni wrote:
>On Mon, Jan 25, 2021 at 07:05:40PM +0100, Florian Obser wrote:
>> Unwind / libunbound goes pretty badly off the rails when an address
>> family is not available, it still tries to talk to nameservers with
>an
>> unreachable address family.
On Mon, Jan 25, 2021 at 06:17:02PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> pf_route() might leak a refence to ifp.
oh no :(
> > Index: sys/net/pf.c
> > ===
> > RCS file: /cvs/src/sys/net/pf.c,v
> > retrieving revision 1.1101
On Mon, Jan 25, 2021 at 02:30:46PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
...
> >
> > i dont understand the kif lifetimes though. can we just point a
> > pdesc at an arbitrary kif or do we need ot reference count?
> >
>
> as long as we don't release NET_LOCK() (or PF_LOCK() in
On Mon, Jan 25, 2021 at 03:21:29PM +0100, Alexander Bluhm wrote:
> Hi,
>
> Some personal thoughts. I am happy when pf route-to gets simpler.
> Especially I have never understood what this address@interface
> syntax is used for.
even after staring at it for so long, i still don't get it. i do
On Mon, Jan 25, 2021 at 04:19:11PM +0100, Alexander Bluhm wrote:
> On Fri, Jan 22, 2021 at 06:07:59PM +1000, David Gwynne wrote:
> > --- sys/conf/GENERIC30 Sep 2020 14:51:17 - 1.273
> > +++ sys/conf/GENERIC22 Jan 2021 07:33:30 -
> > @@ -82,6 +82,7 @@ pseudo-device
On Fri, Jan 22, 2021 at 06:07:59PM +1000, David Gwynne wrote:
> --- sys/conf/GENERIC 30 Sep 2020 14:51:17 - 1.273
> +++ sys/conf/GENERIC 22 Jan 2021 07:33:30 -
> @@ -82,6 +82,7 @@ pseudo-device msts1 # MSTS line discipl
> pseudo-deviceendrun 1 #
hello,
>
> > +pf_route(struct pf_pdesc *pd, struct pf_state *s)
> ...
> > + if (pd->dir == PF_IN) {
> > if (pf_test(AF_INET, PF_OUT, ifp, ) != PF_PASS)
>
> Yes, this is the correct logic. When the packet comes in, pf
> overrides forwarding, tests the out rules, and sends it.
Hello,
On Mon, Jan 25, 2021 at 03:21:29PM +0100, Alexander Bluhm wrote:
> Hi,
>
> Some personal thoughts. I am happy when pf route-to gets simpler.
> Especially I have never understood what this address@interface
> syntax is used for.
>
> I cannot estimate what configuration is used by our
Hi,
Some personal thoughts. I am happy when pf route-to gets simpler.
Especially I have never understood what this address@interface
syntax is used for.
I cannot estimate what configuration is used by our cutomers in
many installations. Simple syntax change address@interface ->
address of next
We are not getting anything useful for us out of it and it can be
quite noisy when we are missing IPv4 or IPv6 addresses as pointed out
by kn@.
It is still available when logging to stderr when running with -d.
OK?
Also shown a revert for a local diff we are carrying, I'll commit that
Hello,
pf_route() might leak a refence to ifp.
> Index: sys/net/pf.c
> ===
> RCS file: /cvs/src/sys/net/pf.c,v
> retrieving revision 1.1101
> diff -u -p -r1.1101 pf.c
> --- sys/net/pf.c 19 Jan 2021 22:22:23 - 1.1101
>
This patch modifies the filterops callback interface so that it becomes
easier to use with fine-grained locking. The current code is an
entanglement of accesses to various data. Some items are more or less
controlled by kqueue, while some others are more or less under the
control of event sources.
On 2020/12/24 18:11, Florian Obser wrote:
> 'tis the season to be jolly...
sorry for the late reply!
> I think it's time to kick the tires on this one.
Works for me, I tried it with the script I'm already using with uacme
to do updates via rndc.
> I don't like the "exec" keyword, we should
On 1/24/21 3:53 PM, Sebastian Benoit wrote:
> And we already have -z for "force grep to behave as zgrep".
Maybe I'm misunderstanding what you're saying, but '-Z' (uppercase) appears to
be the flag for "Force grep to behave as zgrep." The '-z' (lowercase) is
currently unused/invalid in our
On Mon, Jan 25, 2021 at 05:38:40PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
> On Mon, Jan 25, 2021 at 03:21:29PM +0100, Alexander Bluhm wrote:
> > Hi,
> >
> > Some personal thoughts. I am happy when pf route-to gets simpler.
> > Especially I have never understood what this
On Sat, 2021-01-23 at 20:37 +1100, Jonathan Gray wrote:
> On Fri, Jan 22, 2021 at 11:11:27PM -0600, Katherine Rohl wrote:
> > I noticed that large disk volumes cause problems with the formatting of
> > numerical columns in df(1), particularly when using -i. Here's a patch
> > that pads out their
Hi,
I incorrectly ran "systat netstat -N" instead of "systat -N netstat" and
got confused why it wasn't resolving host names. The -N gets parsed with
atof to a 0s delay that is then clamped to 5s. The patch below instead
prints an error if the delay cannot be parsed. I think the <= 0 case
should
On Mon, 2021-01-25 at 08:15 +, Nick Gasson wrote:
> Hi,
>
> I incorrectly ran "systat netstat -N" instead of "systat -N netstat" and
> got confused why it wasn't resolving host names. The -N gets parsed with
> atof to a 0s delay that is then clamped to 5s. The patch below instead
> prints an
Sorry for the delay, it was night in my timezone.
Sebastian Benoit writes:
> Sebastian Benoit(be...@openbsd.org) on 2021.01.25 00:27:05 +0100:
>> Theo de Raadt(dera...@openbsd.org) on 2021.01.24 16:01:32 -0700:
>> > Stuart Henderson wrote:
>> >
>> > > On 2021/01/24 12:10, Theo de Raadt
On 1/24/21 9:01 PM, Alex Henrie wrote:
> I am definitely interested. Bernhard Voelker seemed to express
> interest as well, conditional on -q being added to POSIX first.[1]
Just to clarify: I'm not as enthusiastic to add that option as it
may have sounded.
Let me put it like this: if -q once
On Mon, 2021-01-25 at 10:50 +0100, Martijn van Duren wrote:
> On Mon, 2021-01-25 at 08:15 +, Nick Gasson wrote:
> > Hi,
> >
> > I incorrectly ran "systat netstat -N" instead of "systat -N netstat" and
> > got confused why it wasn't resolving host names. The -N gets parsed with
> > atof to a
Hello,
> >
> > I understand that simple is better here, so I won't object
> > if we will lean towards simplified model above. However I still
> > would like to share my view on current PF.
> >
> > the way I understand how things (should) work currently is fairly
> > simple:
>
On Mon, Jan 25, 2021 at 01:11:35PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
> > >
> > > I understand that simple is better here, so I won't object
> > > if we will lean towards simplified model above. However I still
> > > would like to share my view on current PF.
> > >
> >
Hello,
> >
> > If I understand the idea right, then basically 'match out on em0'
> > figures out the new 'outbound interface' so either 'pass out on em1...'
> > or
> > 'pass out on em2...' will kick in. In other words:
> >
> > depending on the destination picked up from
28 matches
Mail list logo
