<html>
<head>
<base href="https://bugzilla.netfilter.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED - Allow include statement to operate on directories and/or wildcards"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1154#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED - Allow include statement to operate on directories and/or wildcards"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1154">bug 1154</a>
from <span class="vcard"><a class="email" href="mailto:hoxu@users.sf.net" title="hoxu@users.sf.net">hoxu@users.sf.net</a>
</span></b>
<pre>(In reply to Pablo Neira Ayuso from <a href="show_bug.cgi?id=1154#c2">comment #2</a>)
<span class="quote">> We can adopt "directory include" means take all files there from there. No
> need for explicit wildcard. But I would enforce a check for the trailing
> slash probably? So we make explicit for the reader/reviewer that someone is
> importing a directory, not just a file.</span >
Either that, or a separate includedir directive for clarity?
For comparison, here is how sudo does directory inclusion [1]:
```
The #includedir directive can be used to create a sudo.d direc‐
tory that the system package manager can drop sudoers rules
into as part of package installation. For example, given:
#includedir /etc/sudoers.d
sudo will read each file in /etc/sudoers.d, skipping file names
that end in ‘~’ or contain a ‘.’ character to avoid causing
problems with package manager or editor temporary/backup files.
Files are parsed in sorted lexical order. That is,
/etc/sudoers.d/01_first will be parsed before
/etc/sudoers.d/10_second. Be aware that because the sorting is
lexical, not numeric, /etc/sudoers.d/1_whoops would be loaded
after /etc/sudoers.d/10_second. Using a consistent number of
leading zeroes in the file names can be used to avoid such
problems.
```
You may want to consider filtering at least hidden files (.*), which would
nicely exclude vim swapfiles. *~ would do likewise for emacs backup files.
I also like the way debian apache2 does snippet inclusion [2]:
```
# Include generic snippets of statements
IncludeOptional conf-enabled/*.conf
```
Why I'm mentioning apache is to make you consider whether nftables upstream
wants to perhaps nudge downstreams towards - for example - the following
convention:
* /etc/nftables.conf ships with "Include nftables/rules-enabled/*"
* Other packages can ship with suggested rules in /etc/nftables/rules-available
* System admin can cherry-pick rules to symlink to /etc/nftables/rules-enabled
(opening ports by installing a package by default wouldn't work)
Just some random thoughts, in case someone will get brilliant ideas about this.
Personally I would be just happy with a glob include, or failing that, a
directory include.
[1] <a href="https://linux.die.net/man/5/sudoers">https://linux.die.net/man/5/sudoers</a>
[2] <a href="https://httpd.apache.org/docs/2.4/mod/core.html#includeoptional">https://httpd.apache.org/docs/2.4/mod/core.html#includeoptional</a></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>