<html>
<head>
<base href="https://bugzilla.netfilter.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Feature Request - "add set", "add element" - automatically import element members from a file"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1301">1301</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Feature Request - "add set", "add element" - automatically import element members from a file
</td>
</tr>
<tr>
<th>Product</th>
<td>nftables
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86_64
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P5
</td>
</tr>
<tr>
<th>Component</th>
<td>nft
</td>
</tr>
<tr>
<th>Assignee</th>
<td>pablo@netfilter.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>james@nurealm.net
</td>
</tr></table>
<p>
<div>
<pre>After working with "named sets", it would be convenient for nft to learn to
automatically import the "elements" for a "named set" from an external file,
when that list might be very long, as when, for instance, creating a drop rule
for addresses provided from ipdeny.com, rather than always needing to use a
subsequent command, as for instance "nft add element inet filter drop4 \{ $( tr
'\n' ',' < etc/zones.conf.d/cn-aggregated.zone ) \}", in this example.
The format might look something like "set <set_name> { ...; element = {
<file_path>, <element>, ... }", such that the contents of the file are
pulled-in literally as the elements that would otherwise be written to
"elements = { <elements_list> }". Presumably, nft can easily distinguish a
file path, beginning with "/", from any other kind of element in a named set.
Here, "<file_path>" may be used optionally as the first, or only, element of
"<element_list>". Perhaps it is just as easy to allow "<file_path>" to be
placed anywhere in "<element_list>", then also allowing, for instance,
"<file_path>, <file_path>, ... <element>, ..." .
Similarly, for "add/delete element { <element_list> }", the format might simply
be "add/delete element { <file_path>, <element>, ... }".
Additionally, it would be convenient if nft would allow lists of elements in a
file to use alternate separators, such that <new_line> and <tab> characters, in
addition to comma, are acceptable. Lists are commonly provided using
separators other than comma, and it is convenient to not require conversion of
the file before use.
An incidental benefit of allowing nft to import long lists of elements directly
from external files is the opportunity to configure "flags constant", which
perhaps allows some performance advantage, where "constant" cannot be
configured when "nft add element ..." is needed.
Another incidental benefit is the simplification of init configurations, which
invoke nft, which then no longer require additional multiple commands "nft add
element ..." to be configured and executed subsequent to the initial "nft -f
/etc/nftables.conf". For example, no custom modification of the stock
"/usr/lib/systemd/system/nftables.service" would be required to invoke the
additional commands. In particular, systemd service units cannot directly read
file contents, and then something like a "sh" context must be invoked, which
*does* allow file contents to be inserted into commands, as in the example
above. This involves the further inconvenience of requiring additional proper
"escaping" syntax, as the command, as written, is interpreted, for example,
first in systemd context, then in shell context, before finally in nft context.
Proper "escaping" can be a very error prone process, where one wrong character
can cause the entire command set to fail, often without a useful error message.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>