On Sun, 21 Jul 2024, at 12:23 PM, Slavko wrote:
> 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.
I see.
>
>> 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?
You have a point. If on a severely RAM-constrained system, you may prefer to avoid the use of asynchronous pipelines and generate temporary files instead. Doing so would minimise RAM consumption.
#!/bin/sh
set -e
tmpfile1=
tmpfile2=
trap 'rm -f -- "$tmpfile1" "$tmpfile2"' EXIT
tmpfile1=$(mktemp)
tmpfile2=$(mktemp)
cat > "$tmpfile1"
{
echo "delete element $* {"; sed 's/$/,/' "$tmpfile1"; echo "}"
echo "add element $* {"; sed 's/$/,/' "$tmpfile1"; echo "}"
} > "$tmpfile2"
nft -f "$tmpfile2"
In case you are unaware, $* joins the positional parameters by the first character of IFS, which is the space character by default. In other words, the above script consumes newline-delimited addresses from the standard input while expecting to be given the qualified set name as its arguments. Further, it does not require that the input be piped. From a shell, "the-script < address-list.txt" would also work.
>
>> 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?
So it would appear.
>
>> 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").
You are definitely not the only one to think so. Indeed, the matter came up again on IRC just recently. Another complaint that I have frequently encountered is that there is no way to atomically swap sets by name.
--
Kerin Millar
