Re: Sets update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Dňa Sun, 21 Jul 2024 10:58:30 +0100 "Kerin Millar" <kfm@xxxxxxxxxxxxx>
napísal:

> Firstly, you should not use "delete element". It will never be

I am aware of this, but AFAIK the "destroy" is available from kernel 6.3
and i am on 5.15, thus i am out of luck. With any luck, the timeout will
not happen during update (due timeout value and set update interval),
thus in my case it can work reliable.

> Secondly, though you could handle each element one by one, I would
> not recommend it.

OK, i was in doubt.

> Yes, grouping elements in this way is sensible. Note that there is no
> need to worry about the ARG_MAX constraint because nft is being made
> to read from the standard input rather than use the -c option.

I hope in that, don't worry about -c option, i can understand the point
of answer ;-)

> However, I would suggest generating one element per line because the
> way in which nft reports errors is atrocious in the case of long
> lines.

Of course, it was simplified example in mail... Beside of nft errors,
it is more readable in any case...

> {
>    echo "add element ... {"
>    sed 's/$/,/'
>    echo "}"
> } | nft -f -

Eh, that looks really nice (simple), but IMO it is good for (nonexistent
yet) update command. As one needs any IP twice/thrice, thus list must be
read into memory in script, or i miss something?

> add element ... { <existing-ip> timeout <new-timeout> }
> add element ... { <existing-ip> expires <new-timeout> }

In case of existing IP i understand the "add element" as noop (does
nothing) command, thus this is IMO expected.

> I doubt it. Perhaps we need a new "update element" command to act
> similarly to the set statement bearing the same name.

Yes, and while it is possible to update timeout from packet path, it is
surprising, that it is impossible from command line, the code itself
must exists, just user interface is missing?

> Mind you, it gets worse. While the nft utility supports a JSON output
> mode to ease parsing, its output is less accurate than the
> conventional output mode in so far as all "timeout" and "expires"
> values are truncated to integer seconds and conveyed as JSON integers.

I am fain with that timeout precision, mostly because i am not
interested on per element timeouts :-D

I start to play with jq in shell for that, it seems as possible, but
that is in only on my "playing" machine, where i use nftables already.

I am curios why is not possible to directly use ipsets from nftables.
Yes, the nftables's sets are powerful and becomes better, but still are
not direct replacement of ipsets in some cases. Perhaps someone
competent can provide answer (other than "nobody coded it").

regards

-- 
Slavko
https://www.slavino.sk

Attachment: pgpcnZKpEec1Z.pgp
Description: Digitálny podpis OpenPGP


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux